Re: [VOTE] Release Apache Felix SCR 2.2.12
+1 regards, Karl On Thursday, May 2, 2024, Carsten Ziegeler wrote: > +1 > > Carsten > > On 02.05.2024 15:24, Thomas Watson wrote: > >> Hi, >> >> We solved one issues for SCR 2.2.12 >> https://issues.apache.org/jira/projects/FELIX/versions/12354172 >> >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachefelix-1494 >> >> You can use this UNIX script to download the release and verify the >> signatures: >> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh >> >> Usage: >> sh check_staged_release.sh 1493 /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. >> >> Thanks >> Tom >> >> > -- > Carsten Ziegeler > Adobe > cziege...@apache.org > -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Apache Felix SCR 2.2.12
+1 Carsten On 02.05.2024 15:24, Thomas Watson wrote: Hi, We solved one issues for SCR 2.2.12 https://issues.apache.org/jira/projects/FELIX/versions/12354172 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1494 You can use this UNIX script to download the release and verify the signatures: https://github.com/apache/felix-dev/blob/master/check_staged_release.sh Usage: sh check_staged_release.sh 1493 /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. Thanks Tom -- Carsten Ziegeler Adobe cziege...@apache.org
Re: [VOTE] Release Apache Felix SCR 2.2.12
+1 David On Thu, 2 May 2024 at 14:26, Thomas Watson wrote: > Hi, > > We solved one issues for SCR 2.2.12 > https://issues.apache.org/jira/projects/FELIX/versions/12354172 > > > Staging repository: > https://repository.apache.org/content/repositories/orgapachefelix-1494 > > You can use this UNIX script to download the release and verify the > signatures: > https://github.com/apache/felix-dev/blob/master/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1493 /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. > > Thanks > Tom >
[VOTE] Release Apache Felix SCR 2.2.12
Hi, We solved one issues for SCR 2.2.12 https://issues.apache.org/jira/projects/FELIX/versions/12354172 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1494 You can use this UNIX script to download the release and verify the signatures: https://github.com/apache/felix-dev/blob/master/check_staged_release.sh Usage: sh check_staged_release.sh 1493 /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. Thanks Tom
[jira] [Closed] (FELIX-6616) Dynamic greedy 1..1 references may activate with no reference service bound
[ https://issues.apache.org/jira/browse/FELIX-6616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Watson closed FELIX-6616. - > Dynamic greedy 1..1 references may activate with no reference service bound > --- > > Key: FELIX-6616 > URL: https://issues.apache.org/jira/browse/FELIX-6616 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.2.6 >Reporter: Tom Watson >Assignee: Tom Watson >Priority: Major > Fix For: scr-2.2.8, scr-2.2.10 > > > If using a 1..1 cardinality for a dynamic greedy reference there is a timing > issue possible which will cause SCR to unbind all reference when activating > the component. > The timing window involves at least two threads. > 1) thread 1 is in the process of activating the component with a 1..1 dynamic > greedy reference to service X (ranking=1) > 2) thread 2 is in the process of registering another service X with a higher > service ranking=100 > When this happens thread 1 determines it should bind service X ranking 1. > Thread 1 creates the service component instance and enables the tracking of > all the dependencies. It then proceeds to bind all the required services. > Before binding service X ranking=1 thread 2 registers service X ranking=100. > Thread 2 then finds the created service component instance that thread 1 has > created (but is still in the process of binding all the services) and then > thread 2 binds service X ranking=100. At this point thread 2 thinks the > component actually got bound to service X ranking=1 so it begins to unbind > it. Before unbinding, if thread 1 proceeds it will bind service X ranking=1. > So now the component itself (depending on the implementation) will start > using X ranking=1. But then thread 2 proceeds and it will unbind service X > ranking=1. > So basically we are left with this flow: > 1) bind X ranking=100 > 2) bind X ranking=1 > 3) unbind X ranking =1 > At this point the component will be confused and think it likely has no > services to use. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (FELIX-6463) Changing log levels for DS component getState and registration
[ https://issues.apache.org/jira/browse/FELIX-6463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Watson closed FELIX-6463. - > Changing log levels for DS component getState and registration > -- > > Key: FELIX-6463 > URL: https://issues.apache.org/jira/browse/FELIX-6463 > Project: Felix > Issue Type: Improvement > Components: Declarative Services (SCR) >Reporter: Heiko Studt >Assignee: Carsten Ziegeler >Priority: Major > Fix For: scr-2.2.8, scr-2.2.10 > > > As a developer (having the debugger hat), I need to find the most standard > problems most easily. Currently, DS services are logging hundreds and > thousands of lines on startup into DEBUG but nearly nothing into INFO. > So, in my opinion, Felix should reconsider the log levels of all its DS > bundle startup loglines. The two most important ones (in my opinion) are > argued below: > Beginning with AbstractComponentManager::getState. The "Querying state" log > should be in level TRACE, as that very state is written six times(!) for > every state change 3xActivateInteral: (2x inside getState and then again in > the "Activating" line itself) and analogous 3x for the real state change. > Here, all four of these "Querying state" lines are superfluous and only > necessary, if I search for deep felix implementation bugs. > Reference: > [https://github.com/apache/felix-dev/blob/3e5671ae7e5107f4f849ef9d5f0a89b1ba9d7439/scr/src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java#L1427] > Additionally, the registation changes of a component should be logged into > INFO, instead of DEBUG. Then, I do not need to activate DEBUG for my DS based > bundles in the first place (at least for most of my debugging efforts). > [https://github.com/apache/felix-dev/blob/3e5671ae7e5107f4f849ef9d5f0a89b1ba9d7439/scr/src/main/java/org/apache/felix/scr/impl/manager/RegistrationManager.java#L119] > > The two minor changes will improve the debugging experience alot and will > reduce its needed time significantly. I will be glad to create a pull request > if this issue is approved. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (FELIX-6682) Felix SCR - 3 TestCases fail in OSGi TCK
[ https://issues.apache.org/jira/browse/FELIX-6682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Watson closed FELIX-6682. - > Felix SCR - 3 TestCases fail in OSGi TCK > - > > Key: FELIX-6682 > URL: https://issues.apache.org/jira/browse/FELIX-6682 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Reporter: Stefan Bischof >Priority: Major > Fix For: scr-2.2.8, scr-2.2.10 > > > Felix SCR doea not passt the the OSGi TCK with 3 tests. > Versions: 2.2.0-RC - 2.2.6 > https://github.com/osgi/osgi/pull/657 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (FELIX-6699) [DS] Excessive ERROR logging when Overlap in Service-Component header between wildcard and non-wildcard locations
[
https://issues.apache.org/jira/browse/FELIX-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Watson resolved FELIX-6699.
---
Resolution: Fixed
> [DS] Excessive ERROR logging when Overlap in Service-Component header between
> wildcard and non-wildcard locations
> -
>
> Key: FELIX-6699
> URL: https://issues.apache.org/jira/browse/FELIX-6699
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-2.2.10
>Reporter: Mark Adamcin
>Priority: Major
> Labels: patch-available
> Fix For: scr-2.2.12
>
>
> When a bundle's Service-Component header contains explicit paths and wildcard
> paths, it is possible for an explicit descriptor entry to be parsed twice, if
> it is also matched by a wildcard entry. This results in an ERROR level log
> similar to that described in FELIX-2325. The use case which requires this mix
> of wildcard and non-wildcard entries is probably rare, but such is the
> situation with
> [https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/3241]
> In this situation, bnd is used to package the host bundle, and so the
> descriptors for the DS components contained within it are listed explicitly
> in the Service-Component header value generated by the bnd tool.
> Additionally, the project packages some optional component descriptors in a
> sidecar fragment bundle which cannot define its own Service-Component header.
> In order for SCR to load the optional components only when the fragment is
> attached, they must be listed by the host bundle's Service-Component header,
> but only implicitly by using a wildcard, so that their absence is not logged
> when the fragment is not attached.
> Here is an example stack trace:
> {code:java}
> [FelixLogListener]
> com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl bundle
> com.adobe.acs.acs-aem-commons-bundle:6.4.0
> (619)[com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl]
> : Cannot register component (org.apache.felix.log.LogException:
> org.osgi.service.component.ComponentException: The component name
> 'com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl' has
> already been registered by Bundle 619 (com.adobe.acs.acs-aem-commons-bundle)
> as Component of Class
> com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl)
> org.apache.felix.log.LogException:
> org.osgi.service.component.ComponentException: The component name
> 'com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl' has
> already been registered by Bundle 619 (com.adobe.acs.acs-aem-commons-bundle)
> as Component of Class
> com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl
> at
> org.apache.felix.scr.impl.ComponentRegistry.checkComponentName(ComponentRegistry.java:240)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.validateAndRegister(BundleComponentActivator.java:448)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:407)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:283)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.(BundleComponentActivator.java:218)
> at
> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:592)
> at org.apache.felix.scr.impl.Activator.access$200(Activator.java:74)
> at
> org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:460)
> at
> org.apache.felix.scr.impl.AbstractExtender.createExtension(AbstractExtender.java:196)
> at
> org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:169)
> at
> org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:49)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:488)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:420)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:450)
> at
> org.apache.felix.framework.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:915)
> at
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:834)
> at
> org.apache.felix.framework.EventDispatcher.fireBundleEvent(EventDispatcher.java:516)
> at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4847)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2363)
> at
[jira] [Assigned] (FELIX-6699) [DS] Excessive ERROR logging when Overlap in Service-Component header between wildcard and non-wildcard locations
[
https://issues.apache.org/jira/browse/FELIX-6699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tom Watson reassigned FELIX-6699:
-
Assignee: Tom Watson
> [DS] Excessive ERROR logging when Overlap in Service-Component header between
> wildcard and non-wildcard locations
> -
>
> Key: FELIX-6699
> URL: https://issues.apache.org/jira/browse/FELIX-6699
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-2.2.10
>Reporter: Mark Adamcin
>Assignee: Tom Watson
>Priority: Major
> Labels: patch-available
> Fix For: scr-2.2.12
>
>
> When a bundle's Service-Component header contains explicit paths and wildcard
> paths, it is possible for an explicit descriptor entry to be parsed twice, if
> it is also matched by a wildcard entry. This results in an ERROR level log
> similar to that described in FELIX-2325. The use case which requires this mix
> of wildcard and non-wildcard entries is probably rare, but such is the
> situation with
> [https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/3241]
> In this situation, bnd is used to package the host bundle, and so the
> descriptors for the DS components contained within it are listed explicitly
> in the Service-Component header value generated by the bnd tool.
> Additionally, the project packages some optional component descriptors in a
> sidecar fragment bundle which cannot define its own Service-Component header.
> In order for SCR to load the optional components only when the fragment is
> attached, they must be listed by the host bundle's Service-Component header,
> but only implicitly by using a wildcard, so that their absence is not logged
> when the fragment is not attached.
> Here is an example stack trace:
> {code:java}
> [FelixLogListener]
> com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl bundle
> com.adobe.acs.acs-aem-commons-bundle:6.4.0
> (619)[com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl]
> : Cannot register component (org.apache.felix.log.LogException:
> org.osgi.service.component.ComponentException: The component name
> 'com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl' has
> already been registered by Bundle 619 (com.adobe.acs.acs-aem-commons-bundle)
> as Component of Class
> com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl)
> org.apache.felix.log.LogException:
> org.osgi.service.component.ComponentException: The component name
> 'com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl' has
> already been registered by Bundle 619 (com.adobe.acs.acs-aem-commons-bundle)
> as Component of Class
> com.adobe.acs.commons.analysis.jcrchecksum.impl.ChecksumGeneratorImpl
> at
> org.apache.felix.scr.impl.ComponentRegistry.checkComponentName(ComponentRegistry.java:240)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.validateAndRegister(BundleComponentActivator.java:448)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.loadDescriptor(BundleComponentActivator.java:407)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.initialize(BundleComponentActivator.java:283)
> at
> org.apache.felix.scr.impl.BundleComponentActivator.(BundleComponentActivator.java:218)
> at
> org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:592)
> at org.apache.felix.scr.impl.Activator.access$200(Activator.java:74)
> at
> org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:460)
> at
> org.apache.felix.scr.impl.AbstractExtender.createExtension(AbstractExtender.java:196)
> at
> org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:169)
> at
> org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:49)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:488)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:420)
> at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232)
> at
> org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:450)
> at
> org.apache.felix.framework.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:915)
> at
> org.apache.felix.framework.EventDispatcher.fireEventImmediately(EventDispatcher.java:834)
> at
> org.apache.felix.framework.EventDispatcher.fireBundleEvent(EventDispatcher.java:516)
> at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4847)
> at
[jira] [Updated] (FELIX-6667) Reresoliving hosts or resolving new fragments does not invalidate meta-data cache for SCR
[ https://issues.apache.org/jira/browse/FELIX-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Watson updated FELIX-6667: -- Fix Version/s: scr-2.2.10 scr-2.2.8 > Reresoliving hosts or resolving new fragments does not invalidate meta-data > cache for SCR > - > > Key: FELIX-6667 > URL: https://issues.apache.org/jira/browse/FELIX-6667 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.2.6 >Reporter: Tom Watson >Assignee: Tom Watson >Priority: Major > Fix For: scr-2.2.8, scr-2.2.10 > > > There are two cases where the component meta-data that is cached per bundle > does not react to dynamic changes at runtime. > # Fragments are installed and then the host bundle is refreshed to allow the > fragments to attach. The fragments may provide their own component XML > resources. In this case a bundle event is fired indicating the host bundle > got UNRESOLVED. We should remove the cached meta-data for the bundle any > time it gets UNRESOLVED to force it to be re-generated when the host bundle > is activated again with the current set of attached fragments > # Fragments are installed that meet the criteria to allow them to be attached > dynamically to a currently resolved host. In this case we should also force > the host cache to be removed so when the host is re-activated we will > re-generate the meta-data with the current set of resolved fragments. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (FELIX-6633) Dynamic references may miss events while causing deactivation
[ https://issues.apache.org/jira/browse/FELIX-6633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Watson closed FELIX-6633. - > Dynamic references may miss events while causing deactivation > - > > Key: FELIX-6633 > URL: https://issues.apache.org/jira/browse/FELIX-6633 > Project: Felix > Issue Type: Bug > Components: Declarative Services (SCR) >Affects Versions: scr-2.2.6 >Reporter: Tom Watson >Assignee: Tom Watson >Priority: Major > Fix For: scr-2.2.8, scr-2.2.10 > > > This issue sounds similar to issue FELIX-6616 but the cause is much > different. It still involves multiple threads that are > registering/unregistering services that are referenced by a dynamic reference > using 1..1 or m..n where m is >0 (set through configuration admin). > The scenario involves one thread unregistering a service that causes > deactivation while at the same time another thread is registering a service > that would again satisfy the cardinality of the reference. When this > happens the tracker can get into a state where it misses the registration > event while deactivating. > There are probably several ways to fix this, but the most simple seems to be > to add a call to recheck the dependency manager after deactivation. This is > similar to the other reference types that are not dynamic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [VOTE] Release Apache Felix Http Jetty 5.1.12, Http Base 5.1.8, Http Bridge 5.1.8 and parent pom 9
+1 David On Thu, 2 May 2024 at 11:59, Karl Pauls wrote: > +1 > > regards, > > Karl > > On Wed, May 1, 2024 at 10:42 PM Thomas Watson wrote: > > > > +1 > > Tom > > > > > > On Wed, May 1, 2024 at 11:30 AM Carsten Ziegeler > > wrote: > > > > > Hi, > > > > > > we solved two issues for Http Jetty 5.1.12 > > > https://issues.apache.org/jira/projects/FELIX/versions/12354543 > > > > > > we solved one issue for Http Base 5.1.8 > > > https://issues.apache.org/jira/projects/FELIX/versions/12354640 > > > > > > we solved one issue for Http Bridge 5.1.8 > > > https://issues.apache.org/jira/projects/FELIX/versions/12354638 > > > > > > and we solved javadoc generation for Java > 8 in parent pom 9 > > > > > > Staging repository: > > > https://repository.apache.org/content/repositories/orgapachefelix-1492 > > > > > > You can use this UNIX script to download the release and verify the > > > signatures: > > > > https://github.com/apache/felix-dev/blob/master/check_staged_release.sh > > > > > > Usage: > > > sh check_staged_release.sh 1492 /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. > > > > > > Regards > > > Carsten > > > -- > > > Carsten Ziegeler > > > Adobe > > > cziege...@apache.org > > > > > > > -- > Karl Pauls > karlpa...@gmail.com >
Re: [VOTE] Release Apache Felix Http Jetty12 1.0.4
+1 David On Thu, 2 May 2024 at 11:59, Karl Pauls wrote: > +1 > > regards, > > Karl > > On Wed, May 1, 2024 at 10:42 PM Thomas Watson wrote: > > > > +1 > > > > Tom > > > > On Wed, May 1, 2024 at 11:32 AM Carsten Ziegeler > > wrote: > > > > > Hi, > > > > > > we solved four issues for Http Jetty12 1.0.4 > > > https://issues.apache.org/jira/projects/FELIX/versions/12354366 > > > > > > > > > Staging repository: > > > https://repository.apache.org/content/repositories/orgapachefelix-1493 > > > > > > You can use this UNIX script to download the release and verify the > > > signatures: > > > > https://github.com/apache/felix-dev/blob/master/check_staged_release.sh > > > > > > Usage: > > > sh check_staged_release.sh 1493 /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. > > > > > > Regards > > > Carsten > > > -- > > > Carsten Ziegeler > > > Adobe > > > cziege...@apache.org > > > > > > > -- > Karl Pauls > karlpa...@gmail.com >
Re: [VOTE] Release Apache Felix Http Jetty 5.1.12, Http Base 5.1.8, Http Bridge 5.1.8 and parent pom 9
+1 regards, Karl On Wed, May 1, 2024 at 10:42 PM Thomas Watson wrote: > > +1 > Tom > > > On Wed, May 1, 2024 at 11:30 AM Carsten Ziegeler > wrote: > > > Hi, > > > > we solved two issues for Http Jetty 5.1.12 > > https://issues.apache.org/jira/projects/FELIX/versions/12354543 > > > > we solved one issue for Http Base 5.1.8 > > https://issues.apache.org/jira/projects/FELIX/versions/12354640 > > > > we solved one issue for Http Bridge 5.1.8 > > https://issues.apache.org/jira/projects/FELIX/versions/12354638 > > > > and we solved javadoc generation for Java > 8 in parent pom 9 > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachefelix-1492 > > > > You can use this UNIX script to download the release and verify the > > signatures: > > https://github.com/apache/felix-dev/blob/master/check_staged_release.sh > > > > Usage: > > sh check_staged_release.sh 1492 /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. > > > > Regards > > Carsten > > -- > > Carsten Ziegeler > > Adobe > > cziege...@apache.org > > -- Karl Pauls karlpa...@gmail.com
Re: [VOTE] Release Apache Felix Http Jetty12 1.0.4
+1 regards, Karl On Wed, May 1, 2024 at 10:42 PM Thomas Watson wrote: > > +1 > > Tom > > On Wed, May 1, 2024 at 11:32 AM Carsten Ziegeler > wrote: > > > Hi, > > > > we solved four issues for Http Jetty12 1.0.4 > > https://issues.apache.org/jira/projects/FELIX/versions/12354366 > > > > > > Staging repository: > > https://repository.apache.org/content/repositories/orgapachefelix-1493 > > > > You can use this UNIX script to download the release and verify the > > signatures: > > https://github.com/apache/felix-dev/blob/master/check_staged_release.sh > > > > Usage: > > sh check_staged_release.sh 1493 /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. > > > > Regards > > Carsten > > -- > > Carsten Ziegeler > > Adobe > > cziege...@apache.org > > -- Karl Pauls karlpa...@gmail.com
[jira] [Created] (FELIX-6700) Missing OSGi export-package in felix jetty12
Antoine DESSAIGNE created FELIX-6700:
Summary: Missing OSGi export-package in felix jetty12
Key: FELIX-6700
URL: https://issues.apache.org/jira/browse/FELIX-6700
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http.jetty12-1.0.2
Reporter: Antoine DESSAIGNE
Hello everyone,
I just noticed that {{org.apache.felix.http.jetty12.light}} doesn't export the
following packages
{noformat}
org.osgi.service.servlet.context;version="2.0.0";uses:="jakarta.servlet.http,org.osgi.framework"
org.osgi.service.servlet.runtime.dto;version="2.0.0";uses:="org.osgi.dto,org.osgi.framework.dto"
org.osgi.service.servlet.runtime;version="2.0.0";uses:="org.osgi.service.servlet.runtime.dto"
org.osgi.service.servlet.whiteboard;version="2.0.0";uses:="jakarta.servlet"
{noformat}
These packages are present in the jar and contains all the classes present in
{{org.apache.felix.http.bridge}} and this one export the packages.
Is there a reason why they aren't present in the export package instruction of
{{jetty12.light}} ? Thank you for your help
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FELIX-6692) Add Jetty WebSocket support
[ https://issues.apache.org/jira/browse/FELIX-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842862#comment-17842862 ] Paul Rütter (BlueConic) commented on FELIX-6692: Ah sorry, i wasn't aware of that vote process. > Add Jetty WebSocket support > --- > > Key: FELIX-6692 > URL: https://issues.apache.org/jira/browse/FELIX-6692 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: http.jetty12-1.0.4, http.jetty-5.1.12 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FELIX-6692) Add Jetty WebSocket support
[ https://issues.apache.org/jira/browse/FELIX-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842854#comment-17842854 ] Carsten Ziegeler commented on FELIX-6692: - The release vote is currently going on, see Felix dev mailing list. It is open for at least 72 hours, once its closed the artifacts will be available. > Add Jetty WebSocket support > --- > > Key: FELIX-6692 > URL: https://issues.apache.org/jira/browse/FELIX-6692 > Project: Felix > Issue Type: Improvement > Components: HTTP Service >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: http.jetty12-1.0.4, http.jetty-5.1.12 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
