Re: [VOTE] Release Apache Felix Framework 5.6.12

[Carsten Ziegeler]

+1


Jean-baptiste Onofré wrote

Hi all,

We fixed an issue on this release (release notes):
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12344918

This is actually a backport of the fix from Framework 6.0.2 to work with
JDK 11.0.2.
As Felix Framework 5.6.10 is the last version using OSGi R6 (Framework
6.0.x is OSGi R7), I took the liberty (discussed in Jira with Karl) to
create a framework 5.6.x maintenance branch from this tag and backport
the fix.
The framework-5.6.x branch is here:
http://svn.apache.org/repos/asf/felix/branches/org.apache.felix.framework-5.6.x/
As Felix Framework 5.6.x is still used by Apache Karaf 4.2.x (OSGi R6),
and in order to support JDK 11.0.2 in Karaf, we need this fix.
The full OSGi R7 support is planned for Karaf 4.3.x (already started).

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

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.

Thanks,
Regards
JB


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

Re: [VOTE] Release Apache Felix Framework 5.6.12

[Francois Papon]

+1 (non-binding)

Thanks!

Regards,

François Papon
fpa...@apache.org

Le 01/02/2019 à 19:17, Jean-Baptiste Onofré a écrit :
> Hi all,
>
> We fixed an issue on this release (release notes):
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12344918
>
> This is actually a backport of the fix from Framework 6.0.2 to work with
> JDK 11.0.2.
> As Felix Framework 5.6.10 is the last version using OSGi R6 (Framework
> 6.0.x is OSGi R7), I took the liberty (discussed in Jira with Karl) to
> create a framework 5.6.x maintenance branch from this tag and backport
> the fix.
> The framework-5.6.x branch is here:
> http://svn.apache.org/repos/asf/felix/branches/org.apache.felix.framework-5.6.x/
> As Felix Framework 5.6.x is still used by Apache Karaf 4.2.x (OSGi R6),
> and in order to support JDK 11.0.2 in Karaf, we need this fix.
> The full OSGi R7 support is planned for Karaf 4.3.x (already started).
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1283/
>
> 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.
>
> Thanks,
> Regards
> JB

Re: [VOTE] Release for migration testing: Felix Health Check Annotations 0.1.1, Health Check API 0.1.1, Health Check Core 0.1.1, Health Check Webconsole Plugin 0.1.1

[Jean-Baptiste Onofré]

+1 (binding)

Regards
JB

On 01/02/2019 16:00, Georg Henzler wrote:
> Hi all,
> 
> this is a "test release" to be able to validate the modules as version
> 0.1.1 (now with correct export version for API) before releasing 2.0.0.
> 
> We solved 11 issues in this release:
> https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
> 
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1282/
> 
> 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 1282 /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.
> 
> -Georg

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

[jira] [Updated] (FELIX-6045) FileInstall creates bundles from directories

[JIRA]

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

Jean-Baptiste Onofré updated FELIX-6045:

Component/s: File Install

> FileInstall creates bundles from directories
> 
>
> Key: FELIX-6045
> URL: https://issues.apache.org/jira/browse/FELIX-6045
> Project: Felix
>  Issue Type: Bug
>  Components: File Install
> Environment: Windows Server 2016.
>Reporter: Scott Leschke
>Priority: Minor
>
> This behavior was first mentioned in the FELIX-5986 and may be related but 
> may not be so this probably deserves its own issue.
> When starting up using a hot deploy directory hierarchy, bundles get created 
> from a recursive directory scan that begin with the C__ prefix.  These seem 
> as though they may be temporaries that don't get deleted.
> They don't appear to have any purpose as uninstalling them has no noticeable 
> effect.
> Per a note added to FELIX-5986, I believe this issue occurs only on the 
> initial scan of the directory hierarchy as the bundles don't reappear after 
> being uninstalled.



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

[jira] [Assigned] (FELIX-6045) FileInstall creates bundles from directories

[JIRA]

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

Jean-Baptiste Onofré reassigned FELIX-6045:
---

Assignee: Jean-Baptiste Onofré

> FileInstall creates bundles from directories
> 
>
> Key: FELIX-6045
> URL: https://issues.apache.org/jira/browse/FELIX-6045
> Project: Felix
>  Issue Type: Bug
>  Components: File Install
> Environment: Windows Server 2016.
>Reporter: Scott Leschke
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
>
> This behavior was first mentioned in the FELIX-5986 and may be related but 
> may not be so this probably deserves its own issue.
> When starting up using a hot deploy directory hierarchy, bundles get created 
> from a recursive directory scan that begin with the C__ prefix.  These seem 
> as though they may be temporaries that don't get deleted.
> They don't appear to have any purpose as uninstalling them has no noticeable 
> effect.
> Per a note added to FELIX-5986, I believe this issue occurs only on the 
> initial scan of the directory hierarchy as the bundles don't reappear after 
> being uninstalled.



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

Re: [VOTE] Release Apache Felix Framework 5.6.12

[Karl Pauls]

+1

regards,

Karl

On Fri, Feb 1, 2019 at 5:58 PM David Bosschaert
 wrote:
>
> +1
>
> David
>
> On Fri, 1 Feb 2019 at 15:17, Jean-Baptiste Onofré  wrote:
>
> > Hi all,
> >
> > We fixed an issue on this release (release notes):
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12344918
> >
> > This is actually a backport of the fix from Framework 6.0.2 to work with
> > JDK 11.0.2.
> > As Felix Framework 5.6.10 is the last version using OSGi R6 (Framework
> > 6.0.x is OSGi R7), I took the liberty (discussed in Jira with Karl) to
> > create a framework 5.6.x maintenance branch from this tag and backport
> > the fix.
> > The framework-5.6.x branch is here:
> >
> > http://svn.apache.org/repos/asf/felix/branches/org.apache.felix.framework-5.6.x/
> > As Felix Framework 5.6.x is still used by Apache Karaf 4.2.x (OSGi R6),
> > and in order to support JDK 11.0.2 in Karaf, we need this fix.
> > The full OSGi R7 support is planned for Karaf 4.3.x (already started).
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachefelix-1283/
> >
> > 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.
> >
> > Thanks,
> > Regards
> > JB
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Commented] (FELIX-6046) gogo shell interrupts wrong thread on Activator stop

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6046:
---

GitHub user sebratton opened a pull request:

https://github.com/apache/felix/pull/181

FELIX-6046 - fix gogo shell thread interrupt.

proposed fix for FELIX-6046

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sebratton/felix gogo-shell-6046

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/181.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #181


commit ff104db634f48d9009eb51f156400586272c3a29
Author: Samuel E Bratton 
Date:   2019-02-01T21:27:58Z

FELIX-6046 - fix gogo shell thread interrupt.




> gogo shell interrupts wrong thread on Activator stop 
> -
>
> Key: FELIX-6046
> URL: https://issues.apache.org/jira/browse/FELIX-6046
> Project: Felix
>  Issue Type: Bug
>  Components: Gogo Shell
>Affects Versions: gogo.shell-1.1.2
>Reporter: Samuel Bratton
>Priority: Minor
>
> gogo shell interrupts the thread calling stop rather than the shell thread 
> itself.



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

[GitHub] felix pull request #181: FELIX-6046 - fix gogo shell thread interrupt.

[sebratton]

GitHub user sebratton opened a pull request:

https://github.com/apache/felix/pull/181

FELIX-6046 - fix gogo shell thread interrupt.

proposed fix for FELIX-6046

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sebratton/felix gogo-shell-6046

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/181.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #181


commit ff104db634f48d9009eb51f156400586272c3a29
Author: Samuel E Bratton 
Date:   2019-02-01T21:27:58Z

FELIX-6046 - fix gogo shell thread interrupt.




---

[jira] [Created] (FELIX-6046) gogo shell interrupts wrong thread on Activator stop

[Samuel Bratton (JIRA)]

Samuel Bratton created FELIX-6046:
-

 Summary: gogo shell interrupts wrong thread on Activator stop 
 Key: FELIX-6046
 URL: https://issues.apache.org/jira/browse/FELIX-6046
 Project: Felix
  Issue Type: Bug
  Components: Gogo Shell
Affects Versions: gogo.shell-1.1.2
Reporter: Samuel Bratton


gogo shell interrupts the thread calling stop rather than the shell thread 
itself.



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

[jira] [Commented] (FELIX-5986) FielInstall logs ClosedWatchServiceException on Windows

[Scott Leschke (JIRA)]

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

Scott Leschke commented on FELIX-5986:
--

The ClosedWatchServerException now only appears to happen on an initial startup 
of Karaf after a fresh install.  Stopping and restarting Karaf seems to resolve 
the issue.

> FielInstall logs ClosedWatchServiceException on Windows
> ---
>
> Key: FELIX-5986
> URL: https://issues.apache.org/jira/browse/FELIX-5986
> Project: Felix
>  Issue Type: Bug
>  Components: File Install
>Reporter: Scott Leschke
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>  Labels: windows
>
> The following exception stack appears repeatedly/continuously in the log 
> file.  The effect seems to be that temporary bundles starting with C__ that 
> are associated with directories within a recursive directory scan 
> remain.after startup.
> This is relatively recent behavior that seems to have resulted from a 
> reinstall of 4.2.1.
> 2018-11-21T09:05:29,288 | ERROR | fileinstall-C:/BAM | fileinstall | 10 - 
> org.apache.felix.fileinstall - 3.6.4 | In main loop, we have serious trouble
> java.nio.file.ClosedWatchServiceException: null
>  at sun.nio.fs.AbstractWatchService.checkOpen(AbstractWatchService.java:80) 
> ~[?:?]
>  at sun.nio.fs.AbstractWatchService.poll(AbstractWatchService.java:97) ~[?:?]
>  at 
> org.apache.felix.fileinstall.internal.Watcher.processEvents(Watcher.java:163) 
> ~[10:org.apache.felix.fileinstall:3.6.4]
>  at 
> org.apache.felix.fileinstall.internal.WatcherScanner.scan(WatcherScanner.java:63)
>  ~[10:org.apache.felix.fileinstall:3.6.4]
>  at 
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:311)
>  [10:org.apache.felix.fileinstall:3.6.4]



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

[jira] [Created] (FELIX-6045) FileInstall creates bundles from directories

[Scott Leschke (JIRA)]

Scott Leschke created FELIX-6045:


 Summary: FileInstall creates bundles from directories
 Key: FELIX-6045
 URL: https://issues.apache.org/jira/browse/FELIX-6045
 Project: Felix
  Issue Type: Bug
 Environment: Windows Server 2016.
Reporter: Scott Leschke


This behavior was first mentioned in the FELIX-5986 and may be related but may 
not be so this probably deserves its own issue.

When starting up using a hot deploy directory hierarchy, bundles get created 
from a recursive directory scan that begin with the C__ prefix.  These seem as 
though they may be temporaries that don't get deleted.

They don't appear to have any purpose as uninstalling them has no noticeable 
effect.

Per a note added to FELIX-5986, I believe this issue occurs only on the initial 
scan of the directory hierarchy as the bundles don't reappear after being 
uninstalled.



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

Re: [VOTE] Release for migration testing: Felix Health Check Annotations 0.1.1, Health Check API 0.1.1, Health Check Core 0.1.1, Health Check Webconsole Plugin 0.1.1

[Raymond Auge]

+1

- Ray

On Fri, Feb 1, 2019 at 12:43 PM Andrei Dulvac  wrote:

> +1 (non-binding)
>
> - Andrei
>
> On Fri, Feb 1, 2019 at 6:33 PM Karl Pauls  wrote:
>
> > +1
> >
> > regards,
> >
> > Karl
> >
> > On Fri, Feb 1, 2019 at 6:20 PM Christian Schneider
> >  wrote:
> > >
> > > +1 (non binding)
> > >
> > > Christian
> > >
> > > Am Fr., 1. Feb. 2019 um 16:00 Uhr schrieb Georg Henzler <
> > fe...@ghenzler.de>:
> > >
> > > > Hi all,
> > > >
> > > > this is a "test release" to be able to validate the modules as
> version
> > > > 0.1.1 (now with correct export version for API) before releasing
> 2.0.0.
> > > >
> > > > We solved 11 issues in this release:
> > > >
> > > >
> >
> https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
> > > >
> > > > Staging repository:
> > > >
> > https://repository.apache.org/content/repositories/orgapachefelix-1282/
> > > >
> > > > 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 1282 /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.
> > > >
> > > > -Georg
> > > >
> > >
> > >
> > > --
> > > --
> > > Christian Schneider
> > > http://www.liquid-reality.de
> > >
> > > Computer Scientist
> > > http://www.adobe.com
> >
> >
> >
> > --
> > Karl Pauls
> > karlpa...@gmail.com
> >
>


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

[jira] [Commented] (FELIX-6044) Component deactivation does not cause reference services to be ungotten

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on FELIX-6044:
---

GitHub user tjwatson opened a pull request:

https://github.com/apache/felix/pull/180

FELIX-6044 - avoid calling ungetServiceObject too early for simple case of 
SingleRefPair



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tjwatson/felix FELIX-6044

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/180.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #180


commit bf7f727dc812458133e1f8814a9f4ae6b5df3988
Author: Tom Watson 
Date:   2019-02-01T17:28:38Z

FELIX-6044 - avoid calling ungetServiceObject too early for simple case
of SingleRefPair




> Component deactivation does not cause reference services to be ungotten
> ---
>
> Key: FELIX-6044
> URL: https://issues.apache.org/jira/browse/FELIX-6044
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Thomas Watson
>Priority: Major
>
> The fix to FELIX-5974 has caused an issue for the default reference scope of 
> bundle.  When a component has a simple @Reference and that component is 
> deactivated the services that it references will not be ungotten by SCR.  
> This causes all kinds of issues for use counting of the consumed service.
> The issue is that 
> org.apache.felix.scr.impl.manager.DependencyManager.close(ComponentContextImpl,
>  EdgeInfo) is calling RefPair.unsetServiceObject now for all RefPair types.  
> The RefPair types MultiplePrototypeRefPair and SinglePrototypeRefPair were 
> updated to have unsetServiceObject to also have that service be ungotten.  
> But the default SingleRefPair type was not.  This causes issues when 
> ultimately the DependencyManagers are deactivated later which then closes the 
> customizer for the dependency and 
> org.apache.felix.scr.impl.manager.DependencyManager.AbstractCustomizer.ungetService(RefPair  T>) is called.  By this time there will now be a null service and it will 
> not be ungotten.



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

[GitHub] felix pull request #180: FELIX-6044 - avoid calling ungetServiceObject too e...

[tjwatson]

GitHub user tjwatson opened a pull request:

https://github.com/apache/felix/pull/180

FELIX-6044 - avoid calling ungetServiceObject too early for simple case of 
SingleRefPair



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/tjwatson/felix FELIX-6044

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/180.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #180


commit bf7f727dc812458133e1f8814a9f4ae6b5df3988
Author: Tom Watson 
Date:   2019-02-01T17:28:38Z

FELIX-6044 - avoid calling ungetServiceObject too early for simple case
of SingleRefPair




---

Re: [VOTE] Release for migration testing: Felix Health Check Annotations 0.1.1, Health Check API 0.1.1, Health Check Core 0.1.1, Health Check Webconsole Plugin 0.1.1

[Andrei Dulvac]

+1 (non-binding)

- Andrei

On Fri, Feb 1, 2019 at 6:33 PM Karl Pauls  wrote:

> +1
>
> regards,
>
> Karl
>
> On Fri, Feb 1, 2019 at 6:20 PM Christian Schneider
>  wrote:
> >
> > +1 (non binding)
> >
> > Christian
> >
> > Am Fr., 1. Feb. 2019 um 16:00 Uhr schrieb Georg Henzler <
> fe...@ghenzler.de>:
> >
> > > Hi all,
> > >
> > > this is a "test release" to be able to validate the modules as version
> > > 0.1.1 (now with correct export version for API) before releasing 2.0.0.
> > >
> > > We solved 11 issues in this release:
> > >
> > >
> https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
> > >
> > > Staging repository:
> > >
> https://repository.apache.org/content/repositories/orgapachefelix-1282/
> > >
> > > 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 1282 /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.
> > >
> > > -Georg
> > >
> >
> >
> > --
> > --
> > Christian Schneider
> > http://www.liquid-reality.de
> >
> > Computer Scientist
> > http://www.adobe.com
>
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>

Re: [VOTE] Release for migration testing: Felix Health Check Annotations 0.1.1, Health Check API 0.1.1, Health Check Core 0.1.1, Health Check Webconsole Plugin 0.1.1

[Karl Pauls]

+1

regards,

Karl

On Fri, Feb 1, 2019 at 6:20 PM Christian Schneider
 wrote:
>
> +1 (non binding)
>
> Christian
>
> Am Fr., 1. Feb. 2019 um 16:00 Uhr schrieb Georg Henzler :
>
> > Hi all,
> >
> > this is a "test release" to be able to validate the modules as version
> > 0.1.1 (now with correct export version for API) before releasing 2.0.0.
> >
> > We solved 11 issues in this release:
> >
> > https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachefelix-1282/
> >
> > 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 1282 /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.
> >
> > -Georg
> >
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Commented] (FELIX-5974) Prototype scope references are not released on deactivation

[Thomas Watson (JIRA)]

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

Thomas Watson commented on FELIX-5974:
--

Notice that this fix has caused a regression with FELIX-6044

> Prototype scope references are not released on deactivation
> ---
>
> Key: FELIX-5974
> URL: https://issues.apache.org/jira/browse/FELIX-5974
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.12
>Reporter: Timothy Ward
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: scr-2.1.14
>
>
> Having read the stack overflow question on [Stack 
> Overflow|https://stackoverflow.com/questions/52839641/osgi-ds-prototype-reference-not-released]
>  I was pretty certain that the user must be doing something wrong, but in 
> fact it seems as though SCR does a bad job of releasing Prototype scoped 
> references when a component is disposed.
> I looked into the code, and it seems that there are a lot of conflicting 
> locations where prototype scope services are obtained and released. I propose 
> tidying this up so that the ComponentServiceObjects is *always* used 
> internally regardless of whether it is injected or not. This encapsulates all 
> the access in a single location so it is less likely that the objects will 
> leak.



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

[jira] [Created] (FELIX-6044) Component deactivation does not cause reference services to be ungotten

[Thomas Watson (JIRA)]

Thomas Watson created FELIX-6044:


 Summary: Component deactivation does not cause reference services 
to be ungotten
 Key: FELIX-6044
 URL: https://issues.apache.org/jira/browse/FELIX-6044
 Project: Felix
  Issue Type: Bug
  Components: Declarative Services (SCR)
Affects Versions: scr-2.1.14
Reporter: Thomas Watson


The fix to FELIX-5276 has caused an issue for the default reference scope of 
bundle.  When a component has a simple @Reference and that component is 
deactivated the services that it references will not be ungotten by SCR.  This 
causes all kinds of issues for use counting of the consumed service.

The issue is that 
org.apache.felix.scr.impl.manager.DependencyManager.close(ComponentContextImpl,
 EdgeInfo) is calling RefPair.unsetServiceObject now for all RefPair types.  
The RefPair types MultiplePrototypeRefPair and SinglePrototypeRefPair were 
updated to have unsetServiceObject to also have that service be ungotten.  But 
the default SingleRefPair type was not.  This causes issues when ultimately the 
DependencyManagers are deactivated later which then closes the customizer for 
the dependency and 
org.apache.felix.scr.impl.manager.DependencyManager.AbstractCustomizer.ungetService(RefPair) is called.  By this time there will now be a null service and it will not 
be ungotten.



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

[jira] [Updated] (FELIX-6044) Component deactivation does not cause reference services to be ungotten

[Thomas Watson (JIRA)]

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

Thomas Watson updated FELIX-6044:
-
Description: 
The fix to FELIX-5974 has caused an issue for the default reference scope of 
bundle.  When a component has a simple @Reference and that component is 
deactivated the services that it references will not be ungotten by SCR.  This 
causes all kinds of issues for use counting of the consumed service.

The issue is that 
org.apache.felix.scr.impl.manager.DependencyManager.close(ComponentContextImpl,
 EdgeInfo) is calling RefPair.unsetServiceObject now for all RefPair types.  
The RefPair types MultiplePrototypeRefPair and SinglePrototypeRefPair were 
updated to have unsetServiceObject to also have that service be ungotten.  But 
the default SingleRefPair type was not.  This causes issues when ultimately the 
DependencyManagers are deactivated later which then closes the customizer for 
the dependency and 
org.apache.felix.scr.impl.manager.DependencyManager.AbstractCustomizer.ungetService(RefPair) is called.  By this time there will now be a null service and it will not 
be ungotten.

  was:
The fix to FELIX-5276 has caused an issue for the default reference scope of 
bundle.  When a component has a simple @Reference and that component is 
deactivated the services that it references will not be ungotten by SCR.  This 
causes all kinds of issues for use counting of the consumed service.

The issue is that 
org.apache.felix.scr.impl.manager.DependencyManager.close(ComponentContextImpl,
 EdgeInfo) is calling RefPair.unsetServiceObject now for all RefPair types.  
The RefPair types MultiplePrototypeRefPair and SinglePrototypeRefPair were 
updated to have unsetServiceObject to also have that service be ungotten.  But 
the default SingleRefPair type was not.  This causes issues when ultimately the 
DependencyManagers are deactivated later which then closes the customizer for 
the dependency and 
org.apache.felix.scr.impl.manager.DependencyManager.AbstractCustomizer.ungetService(RefPair) is called.  By this time there will now be a null service and it will not 
be ungotten.


> Component deactivation does not cause reference services to be ungotten
> ---
>
> Key: FELIX-6044
> URL: https://issues.apache.org/jira/browse/FELIX-6044
> Project: Felix
>  Issue Type: Bug
>  Components: Declarative Services (SCR)
>Affects Versions: scr-2.1.14
>Reporter: Thomas Watson
>Priority: Major
>
> The fix to FELIX-5974 has caused an issue for the default reference scope of 
> bundle.  When a component has a simple @Reference and that component is 
> deactivated the services that it references will not be ungotten by SCR.  
> This causes all kinds of issues for use counting of the consumed service.
> The issue is that 
> org.apache.felix.scr.impl.manager.DependencyManager.close(ComponentContextImpl,
>  EdgeInfo) is calling RefPair.unsetServiceObject now for all RefPair types.  
> The RefPair types MultiplePrototypeRefPair and SinglePrototypeRefPair were 
> updated to have unsetServiceObject to also have that service be ungotten.  
> But the default SingleRefPair type was not.  This causes issues when 
> ultimately the DependencyManagers are deactivated later which then closes the 
> customizer for the dependency and 
> org.apache.felix.scr.impl.manager.DependencyManager.AbstractCustomizer.ungetService(RefPair  T>) is called.  By this time there will now be a null service and it will 
> not be ungotten.



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

Re: [VOTE] Release for migration testing: Felix Health Check Annotations 0.1.1, Health Check API 0.1.1, Health Check Core 0.1.1, Health Check Webconsole Plugin 0.1.1

[Christian Schneider]

+1 (non binding)

Christian

Am Fr., 1. Feb. 2019 um 16:00 Uhr schrieb Georg Henzler :

> Hi all,
>
> this is a "test release" to be able to validate the modules as version
> 0.1.1 (now with correct export version for API) before releasing 2.0.0.
>
> We solved 11 issues in this release:
>
> https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1282/
>
> 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 1282 /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.
>
> -Georg
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: [VOTE] Release Apache Felix Framework 5.6.12

[David Bosschaert]

+1

David

On Fri, 1 Feb 2019 at 15:17, Jean-Baptiste Onofré  wrote:

> Hi all,
>
> We fixed an issue on this release (release notes):
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12344918
>
> This is actually a backport of the fix from Framework 6.0.2 to work with
> JDK 11.0.2.
> As Felix Framework 5.6.10 is the last version using OSGi R6 (Framework
> 6.0.x is OSGi R7), I took the liberty (discussed in Jira with Karl) to
> create a framework 5.6.x maintenance branch from this tag and backport
> the fix.
> The framework-5.6.x branch is here:
>
> http://svn.apache.org/repos/asf/felix/branches/org.apache.felix.framework-5.6.x/
> As Felix Framework 5.6.x is still used by Apache Karaf 4.2.x (OSGi R6),
> and in order to support JDK 11.0.2 in Karaf, we need this fix.
> The full OSGi R7 support is planned for Karaf 4.3.x (already started).
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1283/
>
> 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.
>
> Thanks,
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [VOTE] Release Apache Felix Framework 5.6.12

[Raymond Auge]

+1

- Ray

On Fri, Feb 1, 2019 at 10:17 AM Jean-Baptiste Onofré 
wrote:

> Hi all,
>
> We fixed an issue on this release (release notes):
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12344918
>
> This is actually a backport of the fix from Framework 6.0.2 to work with
> JDK 11.0.2.
> As Felix Framework 5.6.10 is the last version using OSGi R6 (Framework
> 6.0.x is OSGi R7), I took the liberty (discussed in Jira with Karl) to
> create a framework 5.6.x maintenance branch from this tag and backport
> the fix.
> The framework-5.6.x branch is here:
>
> http://svn.apache.org/repos/asf/felix/branches/org.apache.felix.framework-5.6.x/
> As Felix Framework 5.6.x is still used by Apache Karaf 4.2.x (OSGi R6),
> and in order to support JDK 11.0.2 in Karaf, we need this fix.
> The full OSGi R7 support is planned for Karaf 4.3.x (already started).
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1283/
>
> 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.
>
> Thanks,
> Regards
> JB
> --
> 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)

[GitHub] felix pull request #179: Update SCR dependencies to R7

[pleeplop]

GitHub user pleeplop opened a pull request:

https://github.com/apache/felix/pull/179

Update SCR dependencies to R7

SCR export some OSGi packages (org.osgi.util.promise and uses 
org.osgi.util.function).

So we should update them to the latest release.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/pleeplop/felix scr_r7

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/179.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #179


commit 3bede3b7ebd8196341de9c203e64f406212ac5b8
Author: Adrien Lassere 
Date:   2019-02-01T16:05:30Z

Update dependencies to R7




---

[VOTE] Release Apache Felix Framework 5.6.12

[Jean-Baptiste Onofré]

Hi all,

We fixed an issue on this release (release notes):
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310100&version=12344918

This is actually a backport of the fix from Framework 6.0.2 to work with
JDK 11.0.2.
As Felix Framework 5.6.10 is the last version using OSGi R6 (Framework
6.0.x is OSGi R7), I took the liberty (discussed in Jira with Karl) to
create a framework 5.6.x maintenance branch from this tag and backport
the fix.
The framework-5.6.x branch is here:
http://svn.apache.org/repos/asf/felix/branches/org.apache.felix.framework-5.6.x/
As Felix Framework 5.6.x is still used by Apache Karaf 4.2.x (OSGi R6),
and in order to support JDK 11.0.2 in Karaf, we need this fix.
The full OSGi R7 support is planned for Karaf 4.3.x (already started).

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

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.

Thanks,
Regards
JB
-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

[VOTE] Release for migration testing: Felix Health Check Annotations 0.1.1, Health Check API 0.1.1, Health Check Core 0.1.1, Health Check Webconsole Plugin 0.1.1

[Georg Henzler]

Hi all,

this is a "test release" to be able to validate the modules as version 
0.1.1 (now with correct export version for API) before releasing 2.0.0.


We solved 11 issues in this release:
https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)

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

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 1282 /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.

-Georg

Re: [VOTE] Release for migration testing: Felix Health Check Annotations 0.1.0, Health Check API 0.1.0, Health Check Core 0.1.0, Health Check Webconsole Plugin 0.1.0

[Georg Henzler]

Sigh - we'll have a fixed version in a minute.

On 2019-02-01 15:03, Christian Schneider wrote:

Seems I was too quick.

I just checked the package version of the API packages. It stayed at 
2.0.0.

We must use 0.1.0 there, else the 0.1.0 release would not really help.

So I revert to
-1 (non binding)

Christian

Am Fr., 1. Feb. 2019 um 14:48 Uhr schrieb Christian Schneider <
ch...@die-schneider.net>:


+1 (non binding)

Christian

Am Fr., 1. Feb. 2019 um 14:11 Uhr schrieb Georg Henzler 

>:


Hi all,

this is a "test release" to be able to validate the modules as 
version

0.1.0 before releasing 2.0.0.

We solved 11 issues in this release:

https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6012%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)


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

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 1281 /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.

-Georg




--
--
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com




--

Re: [VOTE] Release for migration testing: Felix Health Check Annotations 0.1.0, Health Check API 0.1.0, Health Check Core 0.1.0, Health Check Webconsole Plugin 0.1.0

[Christian Schneider]

+1 (non binding)

Christian

Am Fr., 1. Feb. 2019 um 14:11 Uhr schrieb Georg Henzler :

> Hi all,
>
> this is a "test release" to be able to validate the modules as version
> 0.1.0 before releasing 2.0.0.
>
> We solved 11 issues in this release:
>
> https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6012%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
>
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachefelix-1281/
>
> 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 1281 /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.
>
> -Georg
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

[jira] [Updated] (FELIX-6035) Allow urlhandlers to create urls for jrt protocol without an add-opens

[JIRA]

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

Jean-Baptiste Onofré updated FELIX-6035:

Affects Version/s: framework-5.6.10

> Allow urlhandlers to create urls for jrt protocol without an add-opens
> --
>
> Key: FELIX-6035
> URL: https://issues.apache.org/jira/browse/FELIX-6035
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-5.6.10, framework-6.0.1
>Reporter: Karl Pauls
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: framework-6.0.2, framework-5.6.12
>
>
> The way we currently look-up and create built-in handlers in the urlhandlers 
> requires the handler package to be open to felix. As this is not the case for 
> the jrt handler by default, the framework needs to be started with an 
> add-opens for the java.base/sun.net.www.protocol.jrt package if jrt urls need 
> to be created. 
> Fortunately. it should be possible to workaround the issue in Felix.



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

[jira] [Commented] (FELIX-6035) Allow urlhandlers to create urls for jrt protocol without an add-opens

[JIRA]

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

Jean-Baptiste Onofré commented on FELIX-6035:
-

Here's the backport on the branch:

https://github.com/apache/felix/commit/0ed09a985001fe48fbd6b6f69031eb885f3711e1

Tested successfully on Karaf 4.2.x, I'm moving forward on the release. Thanks !

> Allow urlhandlers to create urls for jrt protocol without an add-opens
> --
>
> Key: FELIX-6035
> URL: https://issues.apache.org/jira/browse/FELIX-6035
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Karl Pauls
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: framework-6.0.2, framework-5.6.12
>
>
> The way we currently look-up and create built-in handlers in the urlhandlers 
> requires the handler package to be open to felix. As this is not the case for 
> the jrt handler by default, the framework needs to be started with an 
> add-opens for the java.base/sun.net.www.protocol.jrt package if jrt urls need 
> to be created. 
> Fortunately. it should be possible to workaround the issue in Felix.



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

[jira] [Resolved] (FELIX-6035) Allow urlhandlers to create urls for jrt protocol without an add-opens

[JIRA]

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

Jean-Baptiste Onofré resolved FELIX-6035.
-
Resolution: Fixed

> Allow urlhandlers to create urls for jrt protocol without an add-opens
> --
>
> Key: FELIX-6035
> URL: https://issues.apache.org/jira/browse/FELIX-6035
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-5.6.10, framework-6.0.1
>Reporter: Karl Pauls
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: framework-5.6.12, framework-6.0.2
>
>
> The way we currently look-up and create built-in handlers in the urlhandlers 
> requires the handler package to be open to felix. As this is not the case for 
> the jrt handler by default, the framework needs to be started with an 
> add-opens for the java.base/sun.net.www.protocol.jrt package if jrt urls need 
> to be created. 
> Fortunately. it should be possible to workaround the issue in Felix.



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

Re: [VOTE] Release for migration testing: Felix Health Check Annotations 0.1.0, Health Check API 0.1.0, Health Check Core 0.1.0, Health Check Webconsole Plugin 0.1.0

[Christian Schneider]

Seems I was too quick.

I just checked the package version of the API packages. It stayed at 2.0.0.
We must use 0.1.0 there, else the 0.1.0 release would not really help.

So I revert to
-1 (non binding)

Christian

Am Fr., 1. Feb. 2019 um 14:48 Uhr schrieb Christian Schneider <
ch...@die-schneider.net>:

> +1 (non binding)
>
> Christian
>
> Am Fr., 1. Feb. 2019 um 14:11 Uhr schrieb Georg Henzler  >:
>
>> Hi all,
>>
>> this is a "test release" to be able to validate the modules as version
>> 0.1.0 before releasing 2.0.0.
>>
>> We solved 11 issues in this release:
>>
>> https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6012%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)
>>
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachefelix-1281/
>>
>> 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 1281 /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.
>>
>> -Georg
>>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>
>

-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

[Christian Schneider]

With the 0.1.0 release we now have the chance to look into the API without
too much hurry.
So lets check if we would like to have bigger changes but we should not
hold off a stable release for too long.

I think aiming for a stable release in 1-2 weeks should be realistic.

About the release version I do not care too much. For me the main thing to
get right is the package version of the api
as this is what must be semantically versioned.

After writing that I thought it is better to actually check in the 0.1.0
release .. The package version stayed at 2.0.0 .. will have to revert my
vote.

Christian


Am Fr., 1. Feb. 2019 um 14:40 Uhr schrieb Andrei Dulvac :

> Hi Georg.
>
> I don't want to get into a flaming debate about versioning. I've seen on
> the internet what happens.
>
> > So to me it really boils down to not counting down when moving forward
> for
> people upgrading the health checks - it would feel awkward if you had 1.0.2
> and then you use 1.0.0 again
>
> It makes no sense to me, sorry. The namespace is different, it's a
> different lib. The migration path would not be affected at all by this.
> I've seen multiple libraries migrate and reset the version space, which
> makes a lot of sense. (To me, actually having the same version as the sling
> one would be confusing if I needed to migrate, but that's my own view. The
> only libs I've seen that do that are libs with mocks)
>
> > Also the Sling API has been stable for long (Bertrand has done a great
> job
> initially designing it), why would it be all the sudden not good  anymore?
>
> It's at 2.0.0, so well... 1.0.0 wasn't perfect :). But joke aside... I
> expect the need to change the API. What's the purpose of moving the HCs to
> Felix? Broadening the scope, right? This comes with different needs than
> before.
>
> As Ray said, it's weird. Someone might be tempted to release versions in
> sync of the one in sling and the one in felix and that would be a big no-no
> for me.
>
> - Andrei
>
> On Fri, Feb 1, 2019 at 2:07 PM Georg Henzler  wrote:
>
> >
> > I'm taking the hat of the many developers out there in the world that
> > use the API (the ones we cannot talk to and that do not read this
> > mailing list) - 2.0.0 it is to not confuse them. See my response from
> > this morning [1]
> >
> > Also the Sling API has been stable for long (Bertrand has done a great
> > job initially designing it), why would it be all the sudden not good
> > anymore?
> >
> > -Georg
> >
> > [1] https://www.mail-archive.com/dev@felix.apache.org/msg47690.html
> >
> > On 2019-02-01 14:00, Andrei Dulvac wrote:
> > > Hi,
> > >
> > > (Unfortunately I haven't had a chance to look over it properly)
> > >
> > > I'd just like to say I agree with Christian and Ray - a 2.0.0 initial
> > > release is not only weird, but confusing. Why?
> > > I support doing 0.X.0 releases until the api is proven to be stable and
> > > then release *1.0.0*. Why 2.0.0?
> > >
> > > - Andrei
> > >
> > >
> > >
> > > On Fri, Feb 1, 2019 at 1:53 PM Georg Henzler 
> wrote:
> > >
> > >> Hi Bertrand,
> > >>
> > >> > Testing that on snapshots is not optimal IMO as those are
> potentially
> > >> > moving targets.
> > >>
> > >> Let's do it like this then: I'll push a release 0.1.0 today (with
> > >> another short [VOTE] today that I would ask you to quickly vote +1
> > >> for)
> > >> and I'll leave this vote and [1] open until Christian and you had the
> > >> chance to test more in detail with non-SNAPSHOT 0.1.0 artifacts.
> > >>
> > >> End of next week we can then close this vote if there is no good
> > >> reason
> > >> to cancel it.
> > >>
> > >> -Georg
> > >>
> > >> [1]
> > >>
> https://repository.apache.org/content/repositories/orgapachefelix-1279/
> > >>
> > >> On 2019-02-01 12:59, Bertrand Delacretaz wrote:
> > >> > On Thu, Jan 31, 2019 at 5:37 PM Christian Schneider
> > >> >  wrote:
> > >> >> ...How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
> > >> >> It would give people time to test the new project and still allow
> us
> > >> >> to do
> > >> >> incompatible changes
> > >> >
> > >> > I'm also strongly in favor of that, especially as these modules
> > >> > migrated from Sling and people will expect backwards compatibility.
> > >> >
> > >> > Testing that on snapshots is not optimal IMO as those are
> potentially
> > >> > moving targets.
> > >> >
> > >> > Releases are cheap - making another 1.0.0 or 2.0.0 release soon
> > >> > shouldn't be a problem.
> > >> >
> > >> > I'm -0 on releasing these modules as 2.0.0.
> > >> >
> > >> > -Bertrand
> > >>
> >
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

[jira] [Commented] (FELIX-6035) Allow urlhandlers to create urls for jrt protocol without an add-opens

[JIRA]

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

Jean-Baptiste Onofré commented on FELIX-6035:
-

[~karlpauls] but new framework 6 is OSGi R7 right ? I can't change the OSGi 
release on Karaf minor, that's the point. Or Framework 6.x is fully backward 
compatible ?

> Allow urlhandlers to create urls for jrt protocol without an add-opens
> --
>
> Key: FELIX-6035
> URL: https://issues.apache.org/jira/browse/FELIX-6035
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Karl Pauls
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: framework-6.0.2, framework-5.6.12
>
>
> The way we currently look-up and create built-in handlers in the urlhandlers 
> requires the handler package to be open to felix. As this is not the case for 
> the jrt handler by default, the framework needs to be started with an 
> add-opens for the java.base/sun.net.www.protocol.jrt package if jrt urls need 
> to be created. 
> Fortunately. it should be possible to workaround the issue in Felix.



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

[jira] [Commented] (FELIX-6035) Allow urlhandlers to create urls for jrt protocol without an add-opens

[JIRA]

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

Jean-Baptiste Onofré commented on FELIX-6035:
-

[~karlpauls] OSGi R7 is planned for Karaf 4.3.x. That's why, in order to 
support JDK 11 (especially 11.0.2, as it works fine on 11.0.1), on Karaf 4.2.x 
(OSGi R6 still), I would like to do this framework maintenance release.

> Allow urlhandlers to create urls for jrt protocol without an add-opens
> --
>
> Key: FELIX-6035
> URL: https://issues.apache.org/jira/browse/FELIX-6035
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Karl Pauls
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: framework-6.0.2, framework-5.6.12
>
>
> The way we currently look-up and create built-in handlers in the urlhandlers 
> requires the handler package to be open to felix. As this is not the case for 
> the jrt handler by default, the framework needs to be started with an 
> add-opens for the java.base/sun.net.www.protocol.jrt package if jrt urls need 
> to be created. 
> Fortunately. it should be possible to workaround the issue in Felix.



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

[jira] [Commented] (FELIX-6035) Allow urlhandlers to create urls for jrt protocol without an add-opens

[Karl Pauls (JIRA)]

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

Karl Pauls commented on FELIX-6035:
---

[~jbonofre], ah ok - yeah, framework 6 is OSGi R7. If you can't increase the 
OSGi release version that might be a problem. 

> Allow urlhandlers to create urls for jrt protocol without an add-opens
> --
>
> Key: FELIX-6035
> URL: https://issues.apache.org/jira/browse/FELIX-6035
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Karl Pauls
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: framework-6.0.2, framework-5.6.12
>
>
> The way we currently look-up and create built-in handlers in the urlhandlers 
> requires the handler package to be open to felix. As this is not the case for 
> the jrt handler by default, the framework needs to be started with an 
> add-opens for the java.base/sun.net.www.protocol.jrt package if jrt urls need 
> to be created. 
> Fortunately. it should be possible to workaround the issue in Felix.



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

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

[Andrei Dulvac]

Hi Georg.

I don't want to get into a flaming debate about versioning. I've seen on
the internet what happens.

> So to me it really boils down to not counting down when moving forward for
people upgrading the health checks - it would feel awkward if you had 1.0.2
and then you use 1.0.0 again

It makes no sense to me, sorry. The namespace is different, it's a
different lib. The migration path would not be affected at all by this.
I've seen multiple libraries migrate and reset the version space, which
makes a lot of sense. (To me, actually having the same version as the sling
one would be confusing if I needed to migrate, but that's my own view. The
only libs I've seen that do that are libs with mocks)

> Also the Sling API has been stable for long (Bertrand has done a great job
initially designing it), why would it be all the sudden not good  anymore?

It's at 2.0.0, so well... 1.0.0 wasn't perfect :). But joke aside... I
expect the need to change the API. What's the purpose of moving the HCs to
Felix? Broadening the scope, right? This comes with different needs than
before.

As Ray said, it's weird. Someone might be tempted to release versions in
sync of the one in sling and the one in felix and that would be a big no-no
for me.

- Andrei

On Fri, Feb 1, 2019 at 2:07 PM Georg Henzler  wrote:

>
> I'm taking the hat of the many developers out there in the world that
> use the API (the ones we cannot talk to and that do not read this
> mailing list) - 2.0.0 it is to not confuse them. See my response from
> this morning [1]
>
> Also the Sling API has been stable for long (Bertrand has done a great
> job initially designing it), why would it be all the sudden not good
> anymore?
>
> -Georg
>
> [1] https://www.mail-archive.com/dev@felix.apache.org/msg47690.html
>
> On 2019-02-01 14:00, Andrei Dulvac wrote:
> > Hi,
> >
> > (Unfortunately I haven't had a chance to look over it properly)
> >
> > I'd just like to say I agree with Christian and Ray - a 2.0.0 initial
> > release is not only weird, but confusing. Why?
> > I support doing 0.X.0 releases until the api is proven to be stable and
> > then release *1.0.0*. Why 2.0.0?
> >
> > - Andrei
> >
> >
> >
> > On Fri, Feb 1, 2019 at 1:53 PM Georg Henzler  wrote:
> >
> >> Hi Bertrand,
> >>
> >> > Testing that on snapshots is not optimal IMO as those are potentially
> >> > moving targets.
> >>
> >> Let's do it like this then: I'll push a release 0.1.0 today (with
> >> another short [VOTE] today that I would ask you to quickly vote +1
> >> for)
> >> and I'll leave this vote and [1] open until Christian and you had the
> >> chance to test more in detail with non-SNAPSHOT 0.1.0 artifacts.
> >>
> >> End of next week we can then close this vote if there is no good
> >> reason
> >> to cancel it.
> >>
> >> -Georg
> >>
> >> [1]
> >> https://repository.apache.org/content/repositories/orgapachefelix-1279/
> >>
> >> On 2019-02-01 12:59, Bertrand Delacretaz wrote:
> >> > On Thu, Jan 31, 2019 at 5:37 PM Christian Schneider
> >> >  wrote:
> >> >> ...How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
> >> >> It would give people time to test the new project and still allow us
> >> >> to do
> >> >> incompatible changes
> >> >
> >> > I'm also strongly in favor of that, especially as these modules
> >> > migrated from Sling and people will expect backwards compatibility.
> >> >
> >> > Testing that on snapshots is not optimal IMO as those are potentially
> >> > moving targets.
> >> >
> >> > Releases are cheap - making another 1.0.0 or 2.0.0 release soon
> >> > shouldn't be a problem.
> >> >
> >> > I'm -0 on releasing these modules as 2.0.0.
> >> >
> >> > -Bertrand
> >>
>

[VOTE] Release for migration testing: Felix Health Check Annotations 0.1.0, Health Check API 0.1.0, Health Check Core 0.1.0, Health Check Webconsole Plugin 0.1.0

[Georg Henzler]

Hi all,

this is a "test release" to be able to validate the modules as version 
0.1.0 before releasing 2.0.0.


We solved 11 issues in this release:
https://issues.apache.org/jira/issues/?jql=issuekey%20in%20(FELIX-6024%2CFELIX-6025%2CFELIX-6017%2CFELIX-6018%2CFELIX-6016%2CFELIX-6012%2CFELIX-6011%2CFELIX-6010%2CFELIX-6005%2CFELIX-6004%2CFELIX-5952)


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

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 1281 /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.

-Georg

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

[Georg Henzler]

I'm taking the hat of the many developers out there in the world that 
use the API (the ones we cannot talk to and that do not read this 
mailing list) - 2.0.0 it is to not confuse them. See my response from 
this morning [1]


Also the Sling API has been stable for long (Bertrand has done a great 
job initially designing it), why would it be all the sudden not good 
anymore?


-Georg

[1] https://www.mail-archive.com/dev@felix.apache.org/msg47690.html

On 2019-02-01 14:00, Andrei Dulvac wrote:

Hi,

(Unfortunately I haven't had a chance to look over it properly)

I'd just like to say I agree with Christian and Ray - a 2.0.0 initial
release is not only weird, but confusing. Why?
I support doing 0.X.0 releases until the api is proven to be stable and
then release *1.0.0*. Why 2.0.0?

- Andrei



On Fri, Feb 1, 2019 at 1:53 PM Georg Henzler  wrote:


Hi Bertrand,

> Testing that on snapshots is not optimal IMO as those are potentially
> moving targets.

Let's do it like this then: I'll push a release 0.1.0 today (with
another short [VOTE] today that I would ask you to quickly vote +1 
for)

and I'll leave this vote and [1] open until Christian and you had the
chance to test more in detail with non-SNAPSHOT 0.1.0 artifacts.

End of next week we can then close this vote if there is no good 
reason

to cancel it.

-Georg

[1]
https://repository.apache.org/content/repositories/orgapachefelix-1279/

On 2019-02-01 12:59, Bertrand Delacretaz wrote:
> On Thu, Jan 31, 2019 at 5:37 PM Christian Schneider
>  wrote:
>> ...How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
>> It would give people time to test the new project and still allow us
>> to do
>> incompatible changes
>
> I'm also strongly in favor of that, especially as these modules
> migrated from Sling and people will expect backwards compatibility.
>
> Testing that on snapshots is not optimal IMO as those are potentially
> moving targets.
>
> Releases are cheap - making another 1.0.0 or 2.0.0 release soon
> shouldn't be a problem.
>
> I'm -0 on releasing these modules as 2.0.0.
>
> -Bertrand

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

[Andrei Dulvac]

Hi,

(Unfortunately I haven't had a chance to look over it properly)

I'd just like to say I agree with Christian and Ray - a 2.0.0 initial
release is not only weird, but confusing. Why?
I support doing 0.X.0 releases until the api is proven to be stable and
then release *1.0.0*. Why 2.0.0?

- Andrei



On Fri, Feb 1, 2019 at 1:53 PM Georg Henzler  wrote:

> Hi Bertrand,
>
> > Testing that on snapshots is not optimal IMO as those are potentially
> > moving targets.
>
> Let's do it like this then: I'll push a release 0.1.0 today (with
> another short [VOTE] today that I would ask you to quickly vote +1 for)
> and I'll leave this vote and [1] open until Christian and you had the
> chance to test more in detail with non-SNAPSHOT 0.1.0 artifacts.
>
> End of next week we can then close this vote if there is no good reason
> to cancel it.
>
> -Georg
>
> [1]
> https://repository.apache.org/content/repositories/orgapachefelix-1279/
>
> On 2019-02-01 12:59, Bertrand Delacretaz wrote:
> > On Thu, Jan 31, 2019 at 5:37 PM Christian Schneider
> >  wrote:
> >> ...How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
> >> It would give people time to test the new project and still allow us
> >> to do
> >> incompatible changes
> >
> > I'm also strongly in favor of that, especially as these modules
> > migrated from Sling and people will expect backwards compatibility.
> >
> > Testing that on snapshots is not optimal IMO as those are potentially
> > moving targets.
> >
> > Releases are cheap - making another 1.0.0 or 2.0.0 release soon
> > shouldn't be a problem.
> >
> > I'm -0 on releasing these modules as 2.0.0.
> >
> > -Bertrand
>

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

[Georg Henzler]

Hi Bertrand,

Testing that on snapshots is not optimal IMO as those are potentially 
moving targets.


Let's do it like this then: I'll push a release 0.1.0 today (with 
another short [VOTE] today that I would ask you to quickly vote +1 for) 
and I'll leave this vote and [1] open until Christian and you had the 
chance to test more in detail with non-SNAPSHOT 0.1.0 artifacts.


End of next week we can then close this vote if there is no good reason 
to cancel it.


-Georg

[1] 
https://repository.apache.org/content/repositories/orgapachefelix-1279/


On 2019-02-01 12:59, Bertrand Delacretaz wrote:

On Thu, Jan 31, 2019 at 5:37 PM Christian Schneider
 wrote:

...How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
It would give people time to test the new project and still allow us 
to do

incompatible changes


I'm also strongly in favor of that, especially as these modules
migrated from Sling and people will expect backwards compatibility.

Testing that on snapshots is not optimal IMO as those are potentially
moving targets.

Releases are cheap - making another 1.0.0 or 2.0.0 release soon
shouldn't be a problem.

I'm -0 on releasing these modules as 2.0.0.

-Bertrand

Re: [VOTE] Initial release Felix Health Check Annotations 2.0.0, Health Check API 2.0.0, Health Check Core 2.0.0, Health Check General Checks 2.0.0, Health Check Webconsole Plugin 2.0.0

[Bertrand Delacretaz]

On Thu, Jan 31, 2019 at 5:37 PM Christian Schneider
 wrote:
> ...How about releasing 0.1.0 now and release a 2.0.0 in two weeks?
> It would give people time to test the new project and still allow us to do
> incompatible changes

I'm also strongly in favor of that, especially as these modules
migrated from Sling and people will expect backwards compatibility.

Testing that on snapshots is not optimal IMO as those are potentially
moving targets.

Releases are cheap - making another 1.0.0 or 2.0.0 release soon
shouldn't be a problem.

I'm -0 on releasing these modules as 2.0.0.

-Bertrand

[jira] [Commented] (FELIX-6035) Allow urlhandlers to create urls for jrt protocol without an add-opens

[Karl Pauls (JIRA)]

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

Karl Pauls commented on FELIX-6035:
---

[~jbonofre], I'm not totally against it but are you sure it isn't better for 
karaf to switch to the latest framework release instead of maintaining a branch 
(there have been other things that should be working better now for jpms etc.)? 
 

> Allow urlhandlers to create urls for jrt protocol without an add-opens
> --
>
> Key: FELIX-6035
> URL: https://issues.apache.org/jira/browse/FELIX-6035
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Karl Pauls
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: framework-6.0.2, framework-5.6.11
>
>
> The way we currently look-up and create built-in handlers in the urlhandlers 
> requires the handler package to be open to felix. As this is not the case for 
> the jrt handler by default, the framework needs to be started with an 
> add-opens for the java.base/sun.net.www.protocol.jrt package if jrt urls need 
> to be created. 
> Fortunately. it should be possible to workaround the issue in Felix.



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

[jira] [Commented] (FELIX-6035) Allow urlhandlers to create urls for jrt protocol without an add-opens

[JIRA]

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

Jean-Baptiste Onofré commented on FELIX-6035:
-

[~coheigea] I'm tackling that !

> Allow urlhandlers to create urls for jrt protocol without an add-opens
> --
>
> Key: FELIX-6035
> URL: https://issues.apache.org/jira/browse/FELIX-6035
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-6.0.2
>
>
> The way we currently look-up and create built-in handlers in the urlhandlers 
> requires the handler package to be open to felix. As this is not the case for 
> the jrt handler by default, the framework needs to be started with an 
> add-opens for the java.base/sun.net.www.protocol.jrt package if jrt urls need 
> to be created. 
> Fortunately. it should be possible to workaround the issue in Felix.



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

[jira] [Updated] (FELIX-6035) Allow urlhandlers to create urls for jrt protocol without an add-opens

[JIRA]

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

Jean-Baptiste Onofré updated FELIX-6035:

Fix Version/s: framework-5.6.11

> Allow urlhandlers to create urls for jrt protocol without an add-opens
> --
>
> Key: FELIX-6035
> URL: https://issues.apache.org/jira/browse/FELIX-6035
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Karl Pauls
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: framework-6.0.2, framework-5.6.11
>
>
> The way we currently look-up and create built-in handlers in the urlhandlers 
> requires the handler package to be open to felix. As this is not the case for 
> the jrt handler by default, the framework needs to be started with an 
> add-opens for the java.base/sun.net.www.protocol.jrt package if jrt urls need 
> to be created. 
> Fortunately. it should be possible to workaround the issue in Felix.



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

[jira] [Reopened] (FELIX-6035) Allow urlhandlers to create urls for jrt protocol without an add-opens

[JIRA]

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

Jean-Baptiste Onofré reopened FELIX-6035:
-
  Assignee: Jean-Baptiste Onofré  (was: Karl Pauls)

> Allow urlhandlers to create urls for jrt protocol without an add-opens
> --
>
> Key: FELIX-6035
> URL: https://issues.apache.org/jira/browse/FELIX-6035
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Karl Pauls
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: framework-6.0.2
>
>
> The way we currently look-up and create built-in handlers in the urlhandlers 
> requires the handler package to be open to felix. As this is not the case for 
> the jrt handler by default, the framework needs to be started with an 
> add-opens for the java.base/sun.net.www.protocol.jrt package if jrt urls need 
> to be created. 
> Fortunately. it should be possible to workaround the issue in Felix.



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

[jira] [Commented] (FELIX-6035) Allow urlhandlers to create urls for jrt protocol without an add-opens

[JIRA]

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

Jean-Baptiste Onofré commented on FELIX-6035:
-

In order to support JDK 11.0.2 in Karaf, I would like to backport the fix 
(https://github.com/apache/felix/commit/b113094998bce6ca3a0c31b07fd3f5f2f48a1328)
 to Framework 5.6.10 (creating a branch).

No objection ?

> Allow urlhandlers to create urls for jrt protocol without an add-opens
> --
>
> Key: FELIX-6035
> URL: https://issues.apache.org/jira/browse/FELIX-6035
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-6.0.2
>
>
> The way we currently look-up and create built-in handlers in the urlhandlers 
> requires the handler package to be open to felix. As this is not the case for 
> the jrt handler by default, the framework needs to be started with an 
> add-opens for the java.base/sun.net.www.protocol.jrt package if jrt urls need 
> to be created. 
> Fortunately. it should be possible to workaround the issue in Felix.



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

[jira] [Commented] (FELIX-6035) Allow urlhandlers to create urls for jrt protocol without an add-opens

[Colm O hEigeartaigh (JIRA)]

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

Colm O hEigeartaigh commented on FELIX-6035:


Please backport to 5.x as well, as it's causing an issue with Karaf and Java 
11.0.2:
 * Caused by: java.lang.IllegalStateException: Unknown protocol: jrt
 *  at 
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:482)
 *  at 
org.apache.felix.framework.URLHandlersStreamHandlerProxy.toExternalForm(URLHandlersStreamHandlerProxy.java:474)
 *  at java.base/java.net.URL.toExternalForm(URL.java:1001)
 *  at java.base/java.net.URL.toString(URL.java:987)

 
 

 

> Allow urlhandlers to create urls for jrt protocol without an add-opens
> --
>
> Key: FELIX-6035
> URL: https://issues.apache.org/jira/browse/FELIX-6035
> Project: Felix
>  Issue Type: Improvement
>  Components: Framework
>Affects Versions: framework-6.0.1
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>Priority: Major
> Fix For: framework-6.0.2
>
>
> The way we currently look-up and create built-in handlers in the urlhandlers 
> requires the handler package to be open to felix. As this is not the case for 
> the jrt handler by default, the framework needs to be started with an 
> add-opens for the java.base/sun.net.www.protocol.jrt package if jrt urls need 
> to be created. 
> Fortunately. it should be possible to workaround the issue in Felix.



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

[GitHub] felix pull request #178: Added PojoServiceRegistry.registerBundle method

[lefou]

GitHub user lefou opened a pull request:

https://github.com/apache/felix/pull/178

Added PojoServiceRegistry.registerBundle method

Added support to not automatically start scanned bundles. That way, one can 
selectively start (and stop) bundles.

I also added a new config value to disable auto-starting all bundles when 
using the Factory with auto-scanning.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/lefou/felix pojosr

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/felix/pull/178.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #178


commit dc41c44c98b3637209a3e1329909cda86178d348
Author: Tobias Roeser 
Date:   2019-01-29T16:47:13Z

Added PojoServiceRegistry.registerBundle method

Added support to not automatically start scanned bundles.




---