[jira] [Resolved] (ARIES-1927) Applications registered with higher ranking should shadow other applications even if their extensions dependencies are not met
[ https://issues.apache.org/jira/browse/ARIES-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra resolved ARIES-1927. -- Resolution: Fixed > Applications registered with higher ranking should shadow other applications > even if their extensions dependencies are not met > -- > > Key: ARIES-1927 > URL: https://issues.apache.org/jira/browse/ARIES-1927 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.5 >Reporter: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.6 > > > According to the spec any registered application with a higher ranking should > shadow other applications even when the shadowing applications does not have > its extension dependencies fulfilled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARIES-1927) Applications registered with higher ranking should shadow other applications even if their extensions dependencies are not met
[ https://issues.apache.org/jira/browse/ARIES-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra updated ARIES-1927: - Fix Version/s: jax-rs-whiteboard-1.0.6 Affects Version/s: jax-rs-whiteboard-1.0.5 > Applications registered with higher ranking should shadow other applications > even if their extensions dependencies are not met > -- > > Key: ARIES-1927 > URL: https://issues.apache.org/jira/browse/ARIES-1927 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.5 >Reporter: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.6 > > > According to the spec any registered application with a higher ranking should > shadow other applications even when the shadowing applications does not have > its extension dependencies fulfilled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARIES-1929) Performance optimization
[ https://issues.apache.org/jira/browse/ARIES-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra resolved ARIES-1929. -- Resolution: Fixed > Performance optimization > > > Key: ARIES-1929 > URL: https://issues.apache.org/jira/browse/ARIES-1929 > Project: Aries > Issue Type: Improvement > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.5 >Reporter: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.6 > > > Currently the deployment of one application involves a redeployment of the > whole application per service that conforms the application. That means that, > if an application is composed of 20 services it will be rewired 20 times even > if all the services are present when the application is registered. > This should not be necessary and an optimization can be made for the _best > case_, being that all the services are present at the moment of the > application registration so one rewire should be made. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARIES-1929) Performance optimization
[ https://issues.apache.org/jira/browse/ARIES-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra updated ARIES-1929: - Fix Version/s: jax-rs-whiteboard-1.0.6 Affects Version/s: jax-rs-whiteboard-1.0.5 > Performance optimization > > > Key: ARIES-1929 > URL: https://issues.apache.org/jira/browse/ARIES-1929 > Project: Aries > Issue Type: Improvement > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.5 >Reporter: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.6 > > > Currently the deployment of one application involves a redeployment of the > whole application per service that conforms the application. That means that, > if an application is composed of 20 services it will be rewired 20 times even > if all the services are present when the application is registered. > This should not be necessary and an optimization can be made for the _best > case_, being that all the services are present at the moment of the > application registration so one rewire should be made. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARIES-1928) Applications depending on failing extensions should be held undeployed
[ https://issues.apache.org/jira/browse/ARIES-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra updated ARIES-1928: - Fix Version/s: jax-rs-whiteboard-1.0.6 Affects Version/s: jax-rs-whiteboard-1.0.5 > Applications depending on failing extensions should be held undeployed > -- > > Key: ARIES-1928 > URL: https://issues.apache.org/jira/browse/ARIES-1928 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.5 >Reporter: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.6 > > > If application depends on a extensions that fails when it is wired to the > application, the application should be held. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARIES-1928) Applications depending on failing extensions should be held undeployed
[ https://issues.apache.org/jira/browse/ARIES-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra resolved ARIES-1928. -- Resolution: Fixed > Applications depending on failing extensions should be held undeployed > -- > > Key: ARIES-1928 > URL: https://issues.apache.org/jira/browse/ARIES-1928 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.5 >Reporter: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.6 > > > If application depends on a extensions that fails when it is wired to the > application, the application should be held. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARIES-1928) Applications depending on failing extensions should be held undeployed
[ https://issues.apache.org/jira/browse/ARIES-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra updated ARIES-1928: - Fix Version/s: (was: jax-rs-whiteboard-1.0.5) Affects Version/s: (was: jax-rs-whiteboard-1.0.4) > Applications depending on failing extensions should be held undeployed > -- > > Key: ARIES-1928 > URL: https://issues.apache.org/jira/browse/ARIES-1928 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Reporter: Carlos Sierra >Priority: Major > > If application depends on a extensions that fails when it is wired to the > application, the application should be held. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARIES-1929) Performance optimization
[ https://issues.apache.org/jira/browse/ARIES-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra updated ARIES-1929: - Fix Version/s: (was: jax-rs-whiteboard-1.0.5) Affects Version/s: (was: jax-rs-whiteboard-1.0.4) > Performance optimization > > > Key: ARIES-1929 > URL: https://issues.apache.org/jira/browse/ARIES-1929 > Project: Aries > Issue Type: Improvement > Components: jax-rs-whiteboard >Reporter: Carlos Sierra >Priority: Major > > Currently the deployment of one application involves a redeployment of the > whole application per service that conforms the application. That means that, > if an application is composed of 20 services it will be rewired 20 times even > if all the services are present when the application is registered. > This should not be necessary and an optimization can be made for the _best > case_, being that all the services are present at the moment of the > application registration so one rewire should be made. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ARIES-1927) Applications registered with higher ranking should shadow other applications even if their extensions dependencies are not met
[ https://issues.apache.org/jira/browse/ARIES-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra updated ARIES-1927: - Fix Version/s: (was: jax-rs-whiteboard-1.0.5) Affects Version/s: (was: jax-rs-whiteboard-1.0.4) > Applications registered with higher ranking should shadow other applications > even if their extensions dependencies are not met > -- > > Key: ARIES-1927 > URL: https://issues.apache.org/jira/browse/ARIES-1927 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Reporter: Carlos Sierra >Priority: Major > > According to the spec any registered application with a higher ranking should > shadow other applications even when the shadowing applications does not have > its extension dependencies fulfilled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ARIES-1930) Inconsistent error handling
[
https://issues.apache.org/jira/browse/ARIES-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra resolved ARIES-1930.
--
Resolution: Fixed
> Inconsistent error handling
> ---
>
> Key: ARIES-1930
> URL: https://issues.apache.org/jira/browse/ARIES-1930
> Project: Aries
> Issue Type: Bug
> Components: Component DSL
>Affects Versions: component-dsl-1.2.1
>Reporter: Carlos Sierra
>Assignee: Carlos Sierra
>Priority: Major
> Fix For: component-dsl-1.2.2
>
>
> Currenlty unhandled errors happening during execution are not handled
> properly by composite nodes, such as {{just}}, {{all}} or {{distribute}}
> They are correctly bubbling up the exceptions but they are not properly
> closing other executed program nodes, which might lead to unbalanced effects.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Resolved] (ARIES-1926) UpdateSupport is changing effects execution order
[ https://issues.apache.org/jira/browse/ARIES-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra resolved ARIES-1926. -- Resolution: Fixed > UpdateSupport is changing effects execution order > - > > Key: ARIES-1926 > URL: https://issues.apache.org/jira/browse/ARIES-1926 > Project: Aries > Issue Type: Bug > Components: Component DSL >Affects Versions: component-dsl-1.2.1 >Reporter: Carlos Sierra >Priority: Major > Fix For: component-dsl-1.2.2 > > > When running as a result of an update operation, nodes with update support > where reorganizing the effects because the termination was deferred but not > the following adding event. This caused publication of the new event to > happen before the termination of the previous event. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (ARIES-1930) Inconsistent error handling
Carlos Sierra created ARIES-1930:
Summary: Inconsistent error handling
Key: ARIES-1930
URL: https://issues.apache.org/jira/browse/ARIES-1930
Project: Aries
Issue Type: Bug
Components: Component DSL
Affects Versions: component-dsl-1.2.1
Reporter: Carlos Sierra
Assignee: Carlos Sierra
Fix For: component-dsl-1.2.2
Currenlty unhandled errors happening during execution are not handled properly
by composite nodes, such as {{just}}, {{all}} or {{distribute}}
They are correctly bubbling up the exceptions but they are not properly closing
other executed program nodes, which might lead to unbalanced effects.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (ARIES-1929) Performance optimization
Carlos Sierra created ARIES-1929: Summary: Performance optimization Key: ARIES-1929 URL: https://issues.apache.org/jira/browse/ARIES-1929 Project: Aries Issue Type: Improvement Components: jax-rs-whiteboard Affects Versions: jax-rs-whiteboard-1.0.4 Reporter: Carlos Sierra Fix For: jax-rs-whiteboard-1.0.5 Currently the deployment of one application involves a redeployment of the whole application per service that conforms the application. That means that, if an application is composed of 20 services it will be rewired 20 times even if all the services are present when the application is registered. This should not be necessary and an optimization can be made for the _best case_, being that all the services are present at the moment of the application registration so one rewire should be made. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (ARIES-1928) Applications depending on failing extensions should be held undeployed
Carlos Sierra created ARIES-1928: Summary: Applications depending on failing extensions should be held undeployed Key: ARIES-1928 URL: https://issues.apache.org/jira/browse/ARIES-1928 Project: Aries Issue Type: Bug Components: jax-rs-whiteboard Affects Versions: jax-rs-whiteboard-1.0.4 Reporter: Carlos Sierra Fix For: jax-rs-whiteboard-1.0.5 If application depends on a extensions that fails when it is wired to the application, the application should be held. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (ARIES-1927) Applications registered with higher ranking should shadow other applications even if their extensions dependencies are not met
Carlos Sierra created ARIES-1927: Summary: Applications registered with higher ranking should shadow other applications even if their extensions dependencies are not met Key: ARIES-1927 URL: https://issues.apache.org/jira/browse/ARIES-1927 Project: Aries Issue Type: Bug Components: jax-rs-whiteboard Affects Versions: jax-rs-whiteboard-1.0.4 Reporter: Carlos Sierra Fix For: jax-rs-whiteboard-1.0.5 According to the spec any registered application with a higher ranking should shadow other applications even when the shadowing applications does not have its extension dependencies fulfilled. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (ARIES-1926) UpdateSupport is changing effects execution order
Carlos Sierra created ARIES-1926: Summary: UpdateSupport is changing effects execution order Key: ARIES-1926 URL: https://issues.apache.org/jira/browse/ARIES-1926 Project: Aries Issue Type: Bug Components: Component DSL Affects Versions: component-dsl-1.2.1 Reporter: Carlos Sierra Fix For: component-dsl-1.2.2 When running as a result of an update operation, nodes with update support where reorganizing the effects because the termination was deferred but not the following adding event. This caused publication of the new event to happen before the termination of the previous event. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Resolved] (ARIES-1922) Effects is not properly handling exceptions that might happen in the {{onAddedAfter}} event handler
[
https://issues.apache.org/jira/browse/ARIES-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra resolved ARIES-1922.
--
Resolution: Fixed
> Effects is not properly handling exceptions that might happen in the
> {{onAddedAfter}} event handler
> ---
>
> Key: ARIES-1922
> URL: https://issues.apache.org/jira/browse/ARIES-1922
> Project: Aries
> Issue Type: Bug
> Components: Component DSL
>Affects Versions: component-dsl-1.2.1
>Reporter: Carlos Sierra
>Priority: Major
> Fix For: component-dsl-1.2.2
>
>
> in an Effects node, if an error is produced down the chain, there is nothing
> to undo because the chain did not return a closing handler. However, if the
> error is produced in the {{onAddingAfter}} event, the closing handler needs
> to be invoked and the exception rethrown.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (ARIES-1922) Effects is not properly handling exceptions that might happen in the {{onAddedAfter}} event handler
Carlos Sierra created ARIES-1922:
Summary: Effects is not properly handling exceptions that might
happen in the {{onAddedAfter}} event handler
Key: ARIES-1922
URL: https://issues.apache.org/jira/browse/ARIES-1922
Project: Aries
Issue Type: Bug
Components: Component DSL
Affects Versions: component-dsl-1.2.1
Reporter: Carlos Sierra
Fix For: component-dsl-1.2.2
in an Effects node, if an error is produced down the chain, there is nothing to
undo because the chain did not return a closing handler. However, if the error
is produced in the {{onAddingAfter}} event, the closing handler needs to be
invoked and the exception rethrown.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Closed] (ARIES-1912) aries-jaxrs-whiteboard 1.0.4 registers ServletContextHelper with context.path=/
[ https://issues.apache.org/jira/browse/ARIES-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra closed ARIES-1912. Resolution: Not A Bug See comments above. > aries-jaxrs-whiteboard 1.0.4 registers ServletContextHelper with > context.path=/ > --- > > Key: ARIES-1912 > URL: https://issues.apache.org/jira/browse/ARIES-1912 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.4 >Reporter: Nhut Thai Le >Assignee: Carlos Sierra >Priority: Major > Attachments: aries-jaxrs-whiteboard101vs104.PNG, > aries-jaxrs-whiteboard104.PNG > > > We have been using aries-jaxrs-whiteboard to run our REST api along with > paxweb-extender-whiteboard for sometimes. Recently we upgraded > aries-jaxrs-whiteboard from version 1.0.1 to 1.0.4 and noticed that some of > our Servlets/ServletFilters are not working anymore. Digging into paxweb > servlet registration process I found the new aries-jaxrs-whiteboard registers > a cxf-servlet with url pattern /* which makes this servlet a default handler. > Screenshots attached here show the different between aries-jaxrs-whiteboard > 1.0.1 and 1.0.4 in terms of ServletContextHelper and Servlet registration. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (ARIES-1912) aries-jaxrs-whiteboard 1.0.4 registers ServletContextHelper with context.path=/
[ https://issues.apache.org/jira/browse/ARIES-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16849517#comment-16849517 ] Carlos Sierra commented on ARIES-1912: -- Hi [~lnthai2002], is this ticket still an issue for you? Carlos. > aries-jaxrs-whiteboard 1.0.4 registers ServletContextHelper with > context.path=/ > --- > > Key: ARIES-1912 > URL: https://issues.apache.org/jira/browse/ARIES-1912 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.4 >Reporter: Nhut Thai Le >Assignee: Carlos Sierra >Priority: Major > Attachments: aries-jaxrs-whiteboard101vs104.PNG, > aries-jaxrs-whiteboard104.PNG > > > We have been using aries-jaxrs-whiteboard to run our REST api along with > paxweb-extender-whiteboard for sometimes. Recently we upgraded > aries-jaxrs-whiteboard from version 1.0.1 to 1.0.4 and noticed that some of > our Servlets/ServletFilters are not working anymore. Digging into paxweb > servlet registration process I found the new aries-jaxrs-whiteboard registers > a cxf-servlet with url pattern /* which makes this servlet a default handler. > Screenshots attached here show the different between aries-jaxrs-whiteboard > 1.0.1 and 1.0.4 in terms of ServletContextHelper and Servlet registration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARIES-1916) ResourceContext api returns instances that are not handled by OSGi
[
https://issues.apache.org/jira/browse/ARIES-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra resolved ARIES-1916.
--
Resolution: Fixed
Fix Version/s: jax-rs-whiteboard-1.0.5
> ResourceContext api returns instances that are not handled by OSGi
> --
>
> Key: ARIES-1916
> URL: https://issues.apache.org/jira/browse/ARIES-1916
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.4
>Reporter: Carlos Sierra
>Assignee: Carlos Sierra
>Priority: Major
> Fix For: jax-rs-whiteboard-1.0.5
>
>
> When using {{ResourceContext}} JAX-RS API the instances returned are not
> handled by the whiteboard, but created by CXF directly. This is wrong because
> it does not respect the lifecycle of the resources and also skips injection
> of dependencies.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARIES-1914) Extensions that depend on other extensions leave uncleaned state
[ https://issues.apache.org/jira/browse/ARIES-1914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra resolved ARIES-1914. -- Resolution: Fixed Fix Version/s: jax-rs-whiteboard-1.0.5 > Extensions that depend on other extensions leave uncleaned state > > > Key: ARIES-1914 > URL: https://issues.apache.org/jira/browse/ARIES-1914 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.4 >Reporter: Carlos Sierra >Assignee: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.5 > > > Extensions depending on other extensions can only be resolved in the context > of an application. Meaning that, if an extension depends on other extensions > it might be resolved for one application but not in other application. > However this information can not be conveyed properly with the current > structure of the DTOs and the internal structures are also not being properly > cleared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ARIES-1916) ResourceContext api returns instances that are not handled by OSGi
[
https://issues.apache.org/jira/browse/ARIES-1916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra reassigned ARIES-1916:
Assignee: Carlos Sierra
> ResourceContext api returns instances that are not handled by OSGi
> --
>
> Key: ARIES-1916
> URL: https://issues.apache.org/jira/browse/ARIES-1916
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.4
>Reporter: Carlos Sierra
>Assignee: Carlos Sierra
>Priority: Major
>
> When using {{ResourceContext}} JAX-RS API the instances returned are not
> handled by the whiteboard, but created by CXF directly. This is wrong because
> it does not respect the lifecycle of the resources and also skips injection
> of dependencies.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARIES-1916) ResourceContext api returns instances that are not handled by OSGi
Carlos Sierra created ARIES-1916:
Summary: ResourceContext api returns instances that are not
handled by OSGi
Key: ARIES-1916
URL: https://issues.apache.org/jira/browse/ARIES-1916
Project: Aries
Issue Type: Bug
Components: jax-rs-whiteboard
Affects Versions: jax-rs-whiteboard-1.0.4
Reporter: Carlos Sierra
When using {{ResourceContext}} JAX-RS API the instances returned are not
handled by the whiteboard, but created by CXF directly. This is wrong because
it does not respect the lifecycle of the resources and also skips injection of
dependencies.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARIES-1914) Extensions that depend on other extensions leave uncleaned state
Carlos Sierra created ARIES-1914: Summary: Extensions that depend on other extensions leave uncleaned state Key: ARIES-1914 URL: https://issues.apache.org/jira/browse/ARIES-1914 Project: Aries Issue Type: Bug Components: jax-rs-whiteboard Affects Versions: jax-rs-whiteboard-1.0.4 Reporter: Carlos Sierra Assignee: Carlos Sierra Extensions depending on other extensions can only be resolved in the context of an application. Meaning that, if an extension depends on other extensions it might be resolved for one application but not in other application. However this information can not be conveyed properly with the current structure of the DTOs and the internal structures are also not being properly cleared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ARIES-1912) aries-jaxrs-whiteboard 1.0.4 registers ServletContextHelper with context.path=/
[ https://issues.apache.org/jira/browse/ARIES-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra reassigned ARIES-1912: Assignee: Carlos Sierra > aries-jaxrs-whiteboard 1.0.4 registers ServletContextHelper with > context.path=/ > --- > > Key: ARIES-1912 > URL: https://issues.apache.org/jira/browse/ARIES-1912 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.4 >Reporter: Nhut Thai Le >Assignee: Carlos Sierra >Priority: Major > Attachments: aries-jaxrs-whiteboard101vs104.PNG, > aries-jaxrs-whiteboard104.PNG > > > We have been using aries-jaxrs-whiteboard to run our REST api along with > paxweb-extender-whiteboard for sometimes. Recently we upgraded > aries-jaxrs-whiteboard from version 1.0.1 to 1.0.4 and noticed that some of > our Servlets/ServletFilters are not working anymore. Digging into paxweb > servlet registration process I found the new aries-jaxrs-whiteboard registers > a cxf-servlet with url pattern /* which makes this servlet a default handler. > Screenshots attached here show the different between aries-jaxrs-whiteboard > 1.0.1 and 1.0.4 in terms of ServletContextHelper and Servlet registration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1912) aries-jaxrs-whiteboard 1.0.4 registers ServletContextHelper with context.path=/
[ https://issues.apache.org/jira/browse/ARIES-1912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825336#comment-16825336 ] Carlos Sierra commented on ARIES-1912: -- Hi, that servlet context helper might belong to the default application, as described here: https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#service.jaxrs.whiteboard you can check if that is the case if the value of the property "osgi.jaxrs.name" is ".default". In the case of the aries implementation you change its path from the root to a different one. You have two ways of doing so, using configuration or publishing a new application with name ".default" and the desired "osgi.jaxrs.application.base", as stated here: https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#d0e133794. If you choose to use configuration admin to configure the default whiteboard's default application you can create configuration with pid "org.apache.aries.jax.rs.whiteboard.default" and set the property "default.application.base" to the desired path and/or disable the default web by setting the property "default.web" to false. I hope this helps. Carlos. > aries-jaxrs-whiteboard 1.0.4 registers ServletContextHelper with > context.path=/ > --- > > Key: ARIES-1912 > URL: https://issues.apache.org/jira/browse/ARIES-1912 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.4 >Reporter: Nhut Thai Le >Priority: Major > Attachments: aries-jaxrs-whiteboard101vs104.PNG, > aries-jaxrs-whiteboard104.PNG > > > We have been using aries-jaxrs-whiteboard to run our REST api along with > paxweb-extender-whiteboard for sometimes. Recently we upgraded > aries-jaxrs-whiteboard from version 1.0.1 to 1.0.4 and noticed that some of > our Servlets/ServletFilters are not working anymore. Digging into paxweb > servlet registration process I found the new aries-jaxrs-whiteboard registers > a cxf-servlet with url pattern /* which makes this servlet a default handler. > Screenshots attached here show the different between aries-jaxrs-whiteboard > 1.0.1 and 1.0.4 in terms of ServletContextHelper and Servlet registration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARIES-1884) Extensions without "osgi.jaxrs.application.select" property are registering to all available applications
[
https://issues.apache.org/jira/browse/ARIES-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra resolved ARIES-1884.
--
Resolution: Fixed
> Extensions without "osgi.jaxrs.application.select" property are registering
> to all available applications
> -
>
> Key: ARIES-1884
> URL: https://issues.apache.org/jira/browse/ARIES-1884
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.3
>Reporter: Carlos Sierra
>Assignee: Carlos Sierra
>Priority: Major
> Fix For: jax-rs-whiteboard-1.0.4
>
>
> The specification states that, for both resources and extensions, if the
> service does not bear an {{osgi.jaxrs.application.select}} property it should
> attach to the default application in that whiteboard only.
> Currently resources are attaching to default application but extensions are
> attaching to all available applications.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARIES-1892) CxfJaxRSServiceRegistrator might NPE when CXF returns a ClassResourceInfo withh null ResourceProvider
[ https://issues.apache.org/jira/browse/ARIES-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra resolved ARIES-1892. -- Resolution: Fixed > CxfJaxRSServiceRegistrator might NPE when CXF returns a ClassResourceInfo > withh null ResourceProvider > - > > Key: ARIES-1892 > URL: https://issues.apache.org/jira/browse/ARIES-1892 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.3 >Reporter: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARIES-1893) JSX-RS whiteboard is not filling RuntimeDTO.serviceDTO
[ https://issues.apache.org/jira/browse/ARIES-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra resolved ARIES-1893. -- Resolution: Fixed > JSX-RS whiteboard is not filling RuntimeDTO.serviceDTO > -- > > Key: ARIES-1893 > URL: https://issues.apache.org/jira/browse/ARIES-1893 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.3 >Reporter: Carlos Sierra >Assignee: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARIES-1899) Unify configurations between the Whiteboard and the integrations
[ https://issues.apache.org/jira/browse/ARIES-1899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra resolved ARIES-1899. -- Resolution: Fixed > Unify configurations between the Whiteboard and the integrations > > > Key: ARIES-1899 > URL: https://issues.apache.org/jira/browse/ARIES-1899 > Project: Aries > Issue Type: Improvement >Affects Versions: jax-rs-whiteboard-1.0.3 >Reporter: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.4 > > > Currently the whiteboard and the integrations use different strategies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARIES-1899) Unify configurations between the Whiteboard and the integrations
Carlos Sierra created ARIES-1899: Summary: Unify configurations between the Whiteboard and the integrations Key: ARIES-1899 URL: https://issues.apache.org/jira/browse/ARIES-1899 Project: Aries Issue Type: Improvement Affects Versions: jax-rs-whiteboard-1.0.3 Reporter: Carlos Sierra Fix For: jax-rs-whiteboard-1.0.4 Currently the whiteboard and the integrations use different strategies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARIES-1893) JSX-RS whiteboard is not filling RuntimeDTO.serviceDTO
Carlos Sierra created ARIES-1893: Summary: JSX-RS whiteboard is not filling RuntimeDTO.serviceDTO Key: ARIES-1893 URL: https://issues.apache.org/jira/browse/ARIES-1893 Project: Aries Issue Type: Bug Components: jax-rs-whiteboard Affects Versions: jax-rs-whiteboard-1.0.3 Reporter: Carlos Sierra Fix For: jax-rs-whiteboard-1.0.4 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ARIES-1893) JSX-RS whiteboard is not filling RuntimeDTO.serviceDTO
[ https://issues.apache.org/jira/browse/ARIES-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra reassigned ARIES-1893: Assignee: Carlos Sierra > JSX-RS whiteboard is not filling RuntimeDTO.serviceDTO > -- > > Key: ARIES-1893 > URL: https://issues.apache.org/jira/browse/ARIES-1893 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.3 >Reporter: Carlos Sierra >Assignee: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARIES-1892) CxfJaxRSServiceRegistrator might NPE when CXF returns a ClassResourceInfo withh null ResourceProvider
Carlos Sierra created ARIES-1892: Summary: CxfJaxRSServiceRegistrator might NPE when CXF returns a ClassResourceInfo withh null ResourceProvider Key: ARIES-1892 URL: https://issues.apache.org/jira/browse/ARIES-1892 Project: Aries Issue Type: Bug Components: jax-rs-whiteboard Affects Versions: jax-rs-whiteboard-1.0.3 Reporter: Carlos Sierra Fix For: jax-rs-whiteboard-1.0.4 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARIES-1888) JAX-RS Whiteboard is not passing the CT
[ https://issues.apache.org/jira/browse/ARIES-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra resolved ARIES-1888. -- Resolution: Fixed > JAX-RS Whiteboard is not passing the CT > --- > > Key: ARIES-1888 > URL: https://issues.apache.org/jira/browse/ARIES-1888 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.2, jax-rs-whiteboard-1.0.3 >Reporter: Carlos Sierra >Assignee: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARIES-1888) JAX-RS Whiteboard is not passing the CT
Carlos Sierra created ARIES-1888: Summary: JAX-RS Whiteboard is not passing the CT Key: ARIES-1888 URL: https://issues.apache.org/jira/browse/ARIES-1888 Project: Aries Issue Type: Bug Components: jax-rs-whiteboard Affects Versions: jax-rs-whiteboard-1.0.3, jax-rs-whiteboard-1.0.2 Reporter: Carlos Sierra Assignee: Carlos Sierra Fix For: jax-rs-whiteboard-1.0.4 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARIES-1884) Extensions without "osgi.jaxrs.application.select" property are registering to all available applications
Carlos Sierra created ARIES-1884:
Summary: Extensions without "osgi.jaxrs.application.select"
property are registering to all available applications
Key: ARIES-1884
URL: https://issues.apache.org/jira/browse/ARIES-1884
Project: Aries
Issue Type: Bug
Components: jax-rs-whiteboard
Affects Versions: jax-rs-whiteboard-1.0.3
Reporter: Carlos Sierra
Assignee: Carlos Sierra
Fix For: jax-rs-whiteboard-1.0.4
The specification states that, for both resources and extensions, if the
service does not bear an {{osgi.jaxrs.application.select}} property it should
attach to the default application in that whiteboard only.
Currently resources are attaching to default application but extensions are
attaching to all available applications.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1875) JAXRS Whiteboard feature should depend to http-whiteboard servlet
[ https://issues.apache.org/jira/browse/ARIES-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra updated ARIES-1875: - Fix Version/s: (was: jax-rs-whiteboard-1.0.2) jax-rs-whiteboard-1.0.3 > JAXRS Whiteboard feature should depend to http-whiteboard servlet > - > > Key: ARIES-1875 > URL: https://issues.apache.org/jira/browse/ARIES-1875 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: jax-rs-whiteboard-1.0.3 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARIES-1876) Provide feature for jackson integration
[ https://issues.apache.org/jira/browse/ARIES-1876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra updated ARIES-1876: - Fix Version/s: (was: jax-rs-whiteboard-1.0.2) jax-rs-whiteboard-1.0.3 > Provide feature for jackson integration > --- > > Key: ARIES-1876 > URL: https://issues.apache.org/jira/browse/ARIES-1876 > Project: Aries > Issue Type: Improvement > Components: jax-rs-whiteboard >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: jax-rs-whiteboard-1.0.3 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARIES-1874) Servlet registration should use / instead of "" to be compliant with HTTP whiteboard spec
[
https://issues.apache.org/jira/browse/ARIES-1874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra updated ARIES-1874:
-
Affects Version/s: jax-rs-whiteboard-1.0.2
Fix Version/s: (was: jax-rs-whiteboard-1.0.2)
jax-rs-whiteboard-1.0.3
> Servlet registration should use / instead of "" to be compliant with HTTP
> whiteboard spec
> -
>
> Key: ARIES-1874
> URL: https://issues.apache.org/jira/browse/ARIES-1874
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.2, jax-rs-whiteboard-1.0.1
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: jax-rs-whiteboard-1.0.3
>
>
> According to the spec:
> {code}
> For ServletContextHelper services, the value of this service property must be
> of type String. The value is either a slash for the root or it must start
> with a slash but not end with a slash. Valid characters are defined in
> rfc3986#section-3.3. Contexts with an invalid path are ignored.
> {code}
> So, JAXRS Whiteboard should use {{/}} for instance instead of {{""}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1868) @Context injection points are re-injected per request even for singleton resource services
[ https://issues.apache.org/jira/browse/ARIES-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra updated ARIES-1868: - Fix Version/s: jax-rs-whiteboard-1.0.2 > @Context injection points are re-injected per request even for singleton > resource services > -- > > Key: ARIES-1868 > URL: https://issues.apache.org/jira/browse/ARIES-1868 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.2 >Reporter: Carlos Sierra >Assignee: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARIES-1866) URI binding conflict resolution appears incorrect in jaxrs-whiteboard
[
https://issues.apache.org/jira/browse/ARIES-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra resolved ARIES-1866.
--
Resolution: Fixed
> URI binding conflict resolution appears incorrect in jaxrs-whiteboard
> -
>
> Key: ARIES-1866
> URL: https://issues.apache.org/jira/browse/ARIES-1866
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.1
> Environment: I'm using jax-rs whiteboard 1.0.1 on Windows, within
> apache karaf.
>
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Fix For: jax-rs-whiteboard-1.0.2
>
> Attachments: TestResource.java, TestResource2.java
>
>
> I'm seeing different behaviour in the URI resource binding conflict
> resolution when using tje jax-rs whiteboard as then using "plain" cxf.
> Attached are two resource class implementations. One has a class level @Path
> of "test", with then a subresource locator with an @Path of "\{a}" returning
> another resource class that has a @GET with an @Path of "\{b}".
> The other resource class has a class level @Path of "test/a/b".
> Given a GET request for "/test/a/b" it should match the second of these
> resource classes as being the most specific match. Instead it matches the
> first. Indeed it seems that the presence of the first resource class stops
> anything going to the second. If I change the @Path for the second resource
> class to be "test2/a/b" then appropriate requests get routed there.
> I have run a "plain" cxf test by adapting the CXF provided "basic" jax-rs
> test with the same resource classes, and it routes as I would expect.
> I had intended to try and adapt the example in the aries jaxrs whiteboard
> project, but I get test errors when I run an "mvn install",and it isn't
> obvious to me how the jax-rs._example_-run/_example_.jar file mentioned in
> the readme would get created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16709772#comment-16709772
]
Carlos Sierra commented on ARIES-1867:
--
Happy to hear it is working for you :)
> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.2
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: CORSFilter.java, Server.java, TestService3.java,
> make.out, make2.out
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
> private Sse sse;
> private SseBroadcaster eventBroadcaster;
> @Context
> public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
> }
> @GET
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
> }
> }
> {code}
>
>
> In addition, I have a CORS filter:
>
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext,
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin",
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>
> The CORS filter gets fired on all requests as I expect, _except_ for ones to
> the EventResource.subscribeToEvents method. Hence browsers complain when
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level
> issue. I will try and come up with a plain CXF test of the same thing for
> comparison.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1866) URI binding conflict resolution appears incorrect in jaxrs-whiteboard
[
https://issues.apache.org/jira/browse/ARIES-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra updated ARIES-1866:
-
Affects Version/s: jax-rs-whiteboard-1.0.1
Fix Version/s: jax-rs-whiteboard-1.0.2
> URI binding conflict resolution appears incorrect in jaxrs-whiteboard
> -
>
> Key: ARIES-1866
> URL: https://issues.apache.org/jira/browse/ARIES-1866
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.1
> Environment: I'm using jax-rs whiteboard 1.0.1 on Windows, within
> apache karaf.
>
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Fix For: jax-rs-whiteboard-1.0.2
>
> Attachments: TestResource.java, TestResource2.java
>
>
> I'm seeing different behaviour in the URI resource binding conflict
> resolution when using tje jax-rs whiteboard as then using "plain" cxf.
> Attached are two resource class implementations. One has a class level @Path
> of "test", with then a subresource locator with an @Path of "\{a}" returning
> another resource class that has a @GET with an @Path of "\{b}".
> The other resource class has a class level @Path of "test/a/b".
> Given a GET request for "/test/a/b" it should match the second of these
> resource classes as being the most specific match. Instead it matches the
> first. Indeed it seems that the presence of the first resource class stops
> anything going to the second. If I change the @Path for the second resource
> class to be "test2/a/b" then appropriate requests get routed there.
> I have run a "plain" cxf test by adapting the CXF provided "basic" jax-rs
> test with the same resource classes, and it routes as I would expect.
> I had intended to try and adapt the example in the aries jaxrs whiteboard
> project, but I get test errors when I run an "mvn install",and it isn't
> obvious to me how the jax-rs._example_-run/_example_.jar file mentioned in
> the readme would get created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARIES-1868) @Context injection points are re-injected per request even for singleton resource services
[ https://issues.apache.org/jira/browse/ARIES-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra resolved ARIES-1868. -- Resolution: Fixed > @Context injection points are re-injected per request even for singleton > resource services > -- > > Key: ARIES-1868 > URL: https://issues.apache.org/jira/browse/ARIES-1868 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.2 >Reporter: Carlos Sierra >Assignee: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.2 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARIES-1870) URLs are not correctly reported on Windows
[ https://issues.apache.org/jira/browse/ARIES-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra resolved ARIES-1870. -- Resolution: Fixed > URLs are not correctly reported on Windows > -- > > Key: ARIES-1870 > URL: https://issues.apache.org/jira/browse/ARIES-1870 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.2 >Reporter: Carlos Sierra >Assignee: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.2 > > > The report was using FileSystem dependent classes that have different > implementations depending on the operating system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16701004#comment-16701004
]
Carlos Sierra commented on ARIES-1867:
--
I forgot to mention that, during the time of rewiring, it is likely that the
underlying servlet will return 404.
Carlos.
> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.2
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: CORSFilter.java, Server.java, TestService3.java,
> make.out, make2.out
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
> private Sse sse;
> private SseBroadcaster eventBroadcaster;
> @Context
> public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
> }
> @GET
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
> }
> }
> {code}
>
>
> In addition, I have a CORS filter:
>
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext,
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin",
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>
> The CORS filter gets fired on all requests as I expect, _except_ for ones to
> the EventResource.subscribeToEvents method. Hence browsers complain when
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level
> issue. I will try and come up with a plain CXF test of the same thing for
> comparison.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700998#comment-16700998
]
Carlos Sierra commented on ARIES-1867:
--
[~tomq42]
{code:java}
Can you explain to me the circumstances under which the JAX-RS whiteboard
reconfigures?{code}
it _rewires_ the application everytime a change is detected in a resource or an
extension affecting an application. If the properties are modified and those
properties affect the whiteboard it also _rewires_ the application. This is
needed because JAX-RS has not dynamic update of applications.
In the case of extensions, the whiteboard will request a new instance to the
registry everytime an application is boostrapped. If the extension is not
_PROTOTYPE_ scoped, the same instance will be used.
Carlos.
> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.2
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: CORSFilter.java, Server.java, TestService3.java,
> make.out, make2.out
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
> private Sse sse;
> private SseBroadcaster eventBroadcaster;
> @Context
> public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
> }
> @GET
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
> }
> }
> {code}
>
>
> In addition, I have a CORS filter:
>
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext,
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin",
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>
> The CORS filter gets fired on all requests as I expect, _except_ for ones to
> the EventResource.subscribeToEvents method. Hence browsers complain when
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level
> issue. I will try and come up with a plain CXF test of the same thing for
> comparison.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-1870) URLs are not correctly reported on Windows
[ https://issues.apache.org/jira/browse/ARIES-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700740#comment-16700740 ] Carlos Sierra commented on ARIES-1870: -- Hi [~tomq42], this should fix the issues you were having with the tests. Could you verify this works for you now? Bests. Carlos. > URLs are not correctly reported on Windows > -- > > Key: ARIES-1870 > URL: https://issues.apache.org/jira/browse/ARIES-1870 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.2 >Reporter: Carlos Sierra >Assignee: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.2 > > > The report was using FileSystem dependent classes that have different > implementations depending on the operating system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700736#comment-16700736
]
Carlos Sierra commented on ARIES-1867:
--
Hi [~tomq42],
{noformat}
So the SSE example seems to be the special case, and I can (and have) worked
round that as our use of that is limited and I've just manually added the CORS
headers where necessary.{noformat}
I have checked and it looks like CXF _suspends_ the response processing in the
/_subscribe_ method and defers the headers until the first event is sent. I did
not find anywhere saying this is not a proper behavior or that this does not
work with CORS. In any case this would be a bug for CXF.
If we find further evidence that this is a bug in either the whiteboard or CXF
we can reopen this.
Thx.
Carlos.
> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.2
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: CORSFilter.java, Server.java, TestService3.java,
> make.out, make2.out
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
> private Sse sse;
> private SseBroadcaster eventBroadcaster;
> @Context
> public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
> }
> @GET
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
> }
> }
> {code}
>
>
> In addition, I have a CORS filter:
>
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext,
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin",
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>
> The CORS filter gets fired on all requests as I expect, _except_ for ones to
> the EventResource.subscribeToEvents method. Hence browsers complain when
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level
> issue. I will try and come up with a plain CXF test of the same thing for
> comparison.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra closed ARIES-1867.
Resolution: Not A Bug
> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.2
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: CORSFilter.java, Server.java, TestService3.java,
> make.out, make2.out
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
> private Sse sse;
> private SseBroadcaster eventBroadcaster;
> @Context
> public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
> }
> @GET
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
> }
> }
> {code}
>
>
> In addition, I have a CORS filter:
>
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext,
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin",
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>
> The CORS filter gets fired on all requests as I expect, _except_ for ones to
> the EventResource.subscribeToEvents method. Hence browsers complain when
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level
> issue. I will try and come up with a plain CXF test of the same thing for
> comparison.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARIES-1870) URLs are not correctly reported on Windows
Carlos Sierra created ARIES-1870: Summary: URLs are not correctly reported on Windows Key: ARIES-1870 URL: https://issues.apache.org/jira/browse/ARIES-1870 Project: Aries Issue Type: Bug Components: jax-rs-whiteboard Affects Versions: jax-rs-whiteboard-1.0.2 Reporter: Carlos Sierra Assignee: Carlos Sierra Fix For: jax-rs-whiteboard-1.0.2 The report was using FileSystem dependent classes that have different implementations depending on the operating system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700473#comment-16700473
]
Carlos Sierra commented on ARIES-1867:
--
indeed... this was not working on Windows. My bad
Opening a new ticket and fixing.
Thanks for reporting.
Carlos.
> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.2
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: CORSFilter.java, Server.java, TestService3.java,
> make.out, make2.out
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
> private Sse sse;
> private SseBroadcaster eventBroadcaster;
> @Context
> public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
> }
> @GET
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
> }
> }
> {code}
>
>
> In addition, I have a CORS filter:
>
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext,
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin",
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>
> The CORS filter gets fired on all requests as I expect, _except_ for ones to
> the EventResource.subscribeToEvents method. Hence browsers complain when
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level
> issue. I will try and come up with a plain CXF test of the same thing for
> comparison.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16700165#comment-16700165
]
Carlos Sierra commented on ARIES-1867:
--
hey [~tomq42],
no need to apologise :), software is difficult. Your feedback has been very
useful.
Regarding the test failures, they always pass for me. Could you share what
errors are you getting and your environment so I can try to reproduce?
Bests.
Carlos.
> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.2
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: CORSFilter.java, Server.java, TestService3.java
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
> private Sse sse;
> private SseBroadcaster eventBroadcaster;
> @Context
> public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
> }
> @GET
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
> }
> }
> {code}
>
>
> In addition, I have a CORS filter:
>
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext,
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin",
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>
> The CORS filter gets fired on all requests as I expect, _except_ for ones to
> the EventResource.subscribeToEvents method. Hence browsers complain when
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level
> issue. I will try and come up with a plain CXF test of the same thing for
> comparison.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699249#comment-16699249
]
Carlos Sierra commented on ARIES-1867:
--
Hi again [~tomq42],
I have pushed a couple of tests to the whiteboard test suite showing the
behaviour of the whiteboard w.r.t resources returning {{void}} results and
{{ContainerResponseFilter}}. It seems that, in general, the whiteboard is
properly registering the filters for the resources that return {{void}} but, as
you found out, these filters are not invoked in the case of the SSE
{{subscribe}} methods. Could you please verify these assumptions are correct?
My current assumption is that CXF is not handling these properly. I will try
and verify that for the 3.2.5 version, which is the one that the whiteboard is
currently using.
Thx for your report.
Bests.
Carlos.
> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.2
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Blocker
> Attachments: CORSFilter.java, Server.java, TestService3.java
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
> private Sse sse;
> private SseBroadcaster eventBroadcaster;
> @Context
> public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
> }
> @GET
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
> }
> }
> {code}
>
>
> In addition, I have a CORS filter:
>
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext,
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin",
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>
> The CORS filter gets fired on all requests as I expect, _except_ for ones to
> the EventResource.subscribeToEvents method. Hence browsers complain when
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level
> issue. I will try and come up with a plain CXF test of the same thing for
> comparison.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-1866) URI binding conflict resolution appears incorrect in jaxrs-whiteboard
[
https://issues.apache.org/jira/browse/ARIES-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699240#comment-16699240
]
Carlos Sierra commented on ARIES-1866:
--
hey [~tomq42],
it looks like the whiteboard specification is a bit broad to this regard and
the expected behaviour in this case it is not very well defined.
I have pushed a proposed fix in which resource services that do not specify
{{service.ranking}} are considered equal and, thus, not ordered among
themselves so JAX-RS rules should apply.
Before this fix the default {{ServiceReference}} order was applied, so service
resource NEVER clashed because the {{ServiceReference}} ordering was applied.
We have also filed a proposal to ammend the spec and narrow down this expected
behavior.
I have incorporated your tests to the JAX-RS test suite.
I have also released a new snapshot containing this fix. Could you please check
this works for you?
Bests.
Carlos.
> URI binding conflict resolution appears incorrect in jaxrs-whiteboard
> -
>
> Key: ARIES-1866
> URL: https://issues.apache.org/jira/browse/ARIES-1866
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
> Environment: I'm using jax-rs whiteboard 1.0.1 on Windows, within
> apache karaf.
>
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: TestResource.java, TestResource2.java
>
>
> I'm seeing different behaviour in the URI resource binding conflict
> resolution when using tje jax-rs whiteboard as then using "plain" cxf.
> Attached are two resource class implementations. One has a class level @Path
> of "test", with then a subresource locator with an @Path of "\{a}" returning
> another resource class that has a @GET with an @Path of "\{b}".
> The other resource class has a class level @Path of "test/a/b".
> Given a GET request for "/test/a/b" it should match the second of these
> resource classes as being the most specific match. Instead it matches the
> first. Indeed it seems that the presence of the first resource class stops
> anything going to the second. If I change the @Path for the second resource
> class to be "test2/a/b" then appropriate requests get routed there.
> I have run a "plain" cxf test by adapting the CXF provided "basic" jax-rs
> test with the same resource classes, and it routes as I would expect.
> I had intended to try and adapt the example in the aries jaxrs whiteboard
> project, but I get test errors when I run an "mvn install",and it isn't
> obvious to me how the jax-rs._example_-run/_example_.jar file mentioned in
> the readme would get created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699136#comment-16699136
]
Carlos Sierra commented on ARIES-1867:
--
hey [~tomq42],
in a short time I will push my test to upstream. It shows that, as well as CXF,
the whiteboard is *also* invoking the filter for a void returning resource. On
the other hand it also shows that, either the whiteboard or CXF, is not
invoking the filter for the {{subscribe}} method. I would say the problem is on
CXF code because, as you said, most of that logic resides on CXF.
Maybe we can elaborate a bit more on top of the tests to find the discrepancies
we are seeing.
Carlos.
> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.2
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Blocker
> Attachments: CORSFilter.java, Server.java, TestService3.java
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
> private Sse sse;
> private SseBroadcaster eventBroadcaster;
> @Context
> public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
> }
> @GET
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
> }
> }
> {code}
>
>
> In addition, I have a CORS filter:
>
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext,
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin",
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>
> The CORS filter gets fired on all requests as I expect, _except_ for ones to
> the EventResource.subscribeToEvents method. Hence browsers complain when
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level
> issue. I will try and come up with a plain CXF test of the same thing for
> comparison.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16699094#comment-16699094
]
Carlos Sierra commented on ARIES-1867:
--
hey [~tomq42],
I have created a test (not in upstream yet) that shows that the whiteboard is
properly registering a filter for a resource method returning void.
I have also confirmed that the ContainerRequestFilter is, indeed, not invoked
for the usual {{subscribe}} method in the SSE resources. I believe it is CXF
3.2.5 which is causing this but I need to confirm on CXF codebase.
> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.2
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Blocker
> Attachments: CORSFilter.java, Server.java, TestService3.java
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
> private Sse sse;
> private SseBroadcaster eventBroadcaster;
> @Context
> public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
> }
> @GET
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
> }
> }
> {code}
>
>
> In addition, I have a CORS filter:
>
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext,
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin",
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>
> The CORS filter gets fired on all requests as I expect, _except_ for ones to
> the EventResource.subscribeToEvents method. Hence browsers complain when
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level
> issue. I will try and come up with a plain CXF test of the same thing for
> comparison.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARIES-1868) @Context injection points are re-injected per request even for singleton resource services
Carlos Sierra created ARIES-1868: Summary: @Context injection points are re-injected per request even for singleton resource services Key: ARIES-1868 URL: https://issues.apache.org/jira/browse/ARIES-1868 Project: Aries Issue Type: Bug Components: jax-rs-whiteboard Affects Versions: jax-rs-whiteboard-1.0.2 Reporter: Carlos Sierra Assignee: Carlos Sierra -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698713#comment-16698713
]
Carlos Sierra commented on ARIES-1867:
--
Thx... I have removed the link
> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.2
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Blocker
> Attachments: CORSFilter.java, Server.java, TestService3.java
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
> private Sse sse;
> private SseBroadcaster eventBroadcaster;
> @Context
> public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
> }
> @GET
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
> }
> }
> {code}
>
>
> In addition, I have a CORS filter:
>
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext,
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin",
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>
> The CORS filter gets fired on all requests as I expect, _except_ for ones to
> the EventResource.subscribeToEvents method. Hence browsers complain when
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level
> issue. I will try and come up with a plain CXF test of the same thing for
> comparison.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra updated ARIES-1867:
-
Affects Version/s: jax-rs-whiteboard-1.0.2
> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.2
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Blocker
> Attachments: CORSFilter.java, Server.java, TestService3.java
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
> private Sse sse;
> private SseBroadcaster eventBroadcaster;
> @Context
> public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
> }
> @GET
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
> }
> }
> {code}
>
>
> In addition, I have a CORS filter:
>
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext,
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin",
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>
> The CORS filter gets fired on all requests as I expect, _except_ for ones to
> the EventResource.subscribeToEvents method. Hence browsers complain when
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level
> issue. I will try and come up with a plain CXF test of the same thing for
> comparison.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698648#comment-16698648
]
Carlos Sierra commented on ARIES-1867:
--
Hi Tom,
thank you very much for your report. I believe this issue is related to
ARIES-1852. Could you please verify if the latest snapshot that includes a fix
works for you?
Thx.
Carlos.
> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Blocker
> Attachments: CORSFilter.java, Server.java, TestService3.java
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
> private Sse sse;
> private SseBroadcaster eventBroadcaster;
> @Context
> public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
> }
> @GET
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
> }
> }
> {code}
>
>
> In addition, I have a CORS filter:
>
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext,
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin",
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>
> The CORS filter gets fired on all requests as I expect, _except_ for ones to
> the EventResource.subscribeToEvents method. Hence browsers complain when
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level
> issue. I will try and come up with a plain CXF test of the same thing for
> comparison.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16698648#comment-16698648
]
Carlos Sierra edited comment on ARIES-1867 at 11/26/18 9:09 AM:
Hi [~tomq42],
thank you very much for your report. I believe this issue is related to
ARIES-1852. Could you please verify if the latest snapshot that includes a fix
works for you?
Thx.
Carlos.
was (Author: csierra):
Hi Tom,
thank you very much for your report. I believe this issue is related to
ARIES-1852. Could you please verify if the latest snapshot that includes a fix
works for you?
Thx.
Carlos.
> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Blocker
> Attachments: CORSFilter.java, Server.java, TestService3.java
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
> private Sse sse;
> private SseBroadcaster eventBroadcaster;
> @Context
> public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
> }
> @GET
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
> }
> }
> {code}
>
>
> In addition, I have a CORS filter:
>
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext,
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin",
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>
> The CORS filter gets fired on all requests as I expect, _except_ for ones to
> the EventResource.subscribeToEvents method. Hence browsers complain when
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level
> issue. I will try and come up with a plain CXF test of the same thing for
> comparison.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ARIES-1867) ContainerResponseFilter not fired for SSE endpoint
[
https://issues.apache.org/jira/browse/ARIES-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra reassigned ARIES-1867:
Assignee: Carlos Sierra
> ContainerResponseFilter not fired for SSE endpoint
> --
>
> Key: ARIES-1867
> URL: https://issues.apache.org/jira/browse/ARIES-1867
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Blocker
> Attachments: CORSFilter.java, Server.java, TestService3.java
>
>
> I have a resource class such as the following:
> {code:java}
> @Path("events")
> @JaxrsResource
> public class EventsResource {
> private Sse sse;
> private SseBroadcaster eventBroadcaster;
> @Context
> public void setSse(Sse sse) {
> this.sse = sse;
> this.eventBroadcaster = sse.newBroadcaster();
> }
> @GET
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public void suscribeToEvents(@Context SseEventSink eventSink) {
> eventBroadcaster.register(eventSink);
> }
> }
> {code}
>
>
> In addition, I have a CORS filter:
>
> {code:java}
> @Component(immediate=true)
> @Provider
> @JaxrsExtension
> public class CORSFilter implements ContainerResponseFilter {
> @Override
> public void filter(ContainerRequestContext requestContext,
> ContainerResponseContext responseContext) throws IOException {
> System.out.println("CORSFilter for
> "+requestContext.getUriInfo().getPath());
> MultivaluedMap headers = responseContext.getHeaders();
> headers.add("Access-Control-Allow-Origin",
> requestContext.getHeaderString("Origin"));
> ...
> {code}
>
> The CORS filter gets fired on all requests as I expect, _except_ for ones to
> the EventResource.subscribeToEvents method. Hence browsers complain when
> receiving SSE events.
> This used to work fine with jersey as the JAXRS implementation. CORS filter
> got called for the EventsResource.subscribeToEvents call.
> I've no idea whether this is a jaxrs-whiteboard level issue, or a CXF level
> issue. I will try and come up with a plain CXF test of the same thing for
> comparison.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ARIES-1866) URI binding conflict resolution appears incorrect in jaxrs-whiteboard
[
https://issues.apache.org/jira/browse/ARIES-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra reassigned ARIES-1866:
Assignee: Carlos Sierra
> URI binding conflict resolution appears incorrect in jaxrs-whiteboard
> -
>
> Key: ARIES-1866
> URL: https://issues.apache.org/jira/browse/ARIES-1866
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
> Environment: I'm using jax-rs whiteboard 1.0.1 on Windows, within
> apache karaf.
>
>Reporter: Tom Quarendon
>Assignee: Carlos Sierra
>Priority: Major
> Attachments: TestResource.java, TestResource2.java
>
>
> I'm seeing different behaviour in the URI resource binding conflict
> resolution when using tje jax-rs whiteboard as then using "plain" cxf.
> Attached are two resource class implementations. One has a class level @Path
> of "test", with then a subresource locator with an @Path of "\{a}" returning
> another resource class that has a @GET with an @Path of "\{b}".
> The other resource class has a class level @Path of "test/a/b".
> Given a GET request for "/test/a/b" it should match the second of these
> resource classes as being the most specific match. Instead it matches the
> first. Indeed it seems that the presence of the first resource class stops
> anything going to the second. If I change the @Path for the second resource
> class to be "test2/a/b" then appropriate requests get routed there.
> I have run a "plain" cxf test by adapting the CXF provided "basic" jax-rs
> test with the same resource classes, and it routes as I would expect.
> I had intended to try and adapt the example in the aries jaxrs whiteboard
> project, but I get test errors when I run an "mvn install",and it isn't
> obvious to me how the jax-rs._example_-run/_example_.jar file mentioned in
> the readme would get created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARIES-1865) IllegalArgumentException in ServiceTuple
[ https://issues.apache.org/jira/browse/ARIES-1865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra resolved ARIES-1865. -- Resolution: Fixed > IllegalArgumentException in ServiceTuple > > > Key: ARIES-1865 > URL: https://issues.apache.org/jira/browse/ARIES-1865 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.1 >Reporter: Carlos Sierra >Assignee: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.2 > > > It looks like, under some circumstances, some of the services in the tuples > are tried to be _ungot_ twice, causing an IllegalArgumentException to be > thrown -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARIES-1865) IllegalArgumentException in ServiceTuple
Carlos Sierra created ARIES-1865: Summary: IllegalArgumentException in ServiceTuple Key: ARIES-1865 URL: https://issues.apache.org/jira/browse/ARIES-1865 Project: Aries Issue Type: Bug Components: jax-rs-whiteboard Affects Versions: jax-rs-whiteboard-1.0.1 Reporter: Carlos Sierra Assignee: Carlos Sierra Fix For: jax-rs-whiteboard-1.0.2 It looks like, under some circumstances, some of the services in the tuples are tried to be _ungot_ twice, causing an IllegalArgumentException to be thrown -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ARIES-1856) Issue with redeployment in Bndtools
[ https://issues.apache.org/jira/browse/ARIES-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672838#comment-16672838 ] Carlos Sierra edited comment on ARIES-1856 at 11/2/18 9:57 AM: --- hey, I believe this could be a different manifestation of this issue https://issues.apache.org/jira/browse/ARIES-1843 ... could you try using the latest snapshot containing this fix? Bests. Carlos. was (Author: csierra): hey, I believe this could be a different manifestation of this issue... could you try using the latest snapshot containing this fix? Bests. Carlos. > Issue with redeployment in Bndtools > --- > > Key: ARIES-1856 > URL: https://issues.apache.org/jira/browse/ARIES-1856 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.1 >Reporter: Timothy Ward >Assignee: Carlos Sierra >Priority: Major > > When using Bndtools for development there are many redeploys of the JAX-RS > whiteboard bundle (the bundle gets rebuilt on save). For some reason I am > seeing an NPE, after which my application is broken until I restart the > framework. > This is happening using the OSGi enRoute 7.0.0 templates. > > java.lang.NullPointerException: null > at > org.apache.aries.jax.rs.whiteboard.internal.utils.ServiceReferenceResourceProvider.getResourceClass(ServiceReferenceResourceProvider.java:56) > at > org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setResourceProviders(JAXRSServerFactoryBean.java:391) > at > org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setResourceProvider(JAXRSServerFactoryBean.java:381) > at > org.apache.aries.jax.rs.whiteboard.internal.cxf.CxfJaxrsServiceRegistrator.rewire(CxfJaxrsServiceRegistrator.java:282) > at > org.apache.aries.jax.rs.whiteboard.internal.cxf.CxfJaxrsServiceRegistrator.remove(CxfJaxrsServiceRegistrator.java:178) > at > org.apache.aries.jax.rs.whiteboard.internal.cxf.CxfJaxrsServiceRegistrator.add(CxfJaxrsServiceRegistrator.java:90) > at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:615) > at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:618) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28) > at org.apache.aries.component.dsl.OSGi.lambda$null$76(OSGi.java:710) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:25) > at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) > at java.util.Collections$2.tryAdvance(Collections.java:4717) > at java.util.Collections$2.forEachRemaining(Collections.java:4725) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) > at > org.apache.aries.component.dsl.internal.JustOSGiImpl.lambda$new$2(JustOSGiImpl.java:42) > at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50) > at org.apache.aries.component.dsl.OSGi.lambda$map$77(OSGi.java:710) > at > org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39) > at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50) > at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612) > at > org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39) > at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50) > at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612) > at > org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39) > at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50) > at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612) > at > org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39) > at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50) > at org.apache.aries.component.dsl.OSGi.lambda$null$73(OSGi.java:694) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28) > at org.apache.aries.component.dsl.OSGi.lambda$null$80(OSGi.java:735) > at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:618) > at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:618) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:25) > at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) > at java.util.Collections$2.tryAdvance(Collections.java:4717) > at
[jira] [Commented] (ARIES-1856) Issue with redeployment in Bndtools
[ https://issues.apache.org/jira/browse/ARIES-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672838#comment-16672838 ] Carlos Sierra commented on ARIES-1856: -- hey, I believe this could be a different manifestation of this issue... could you try using the latest snapshot containing this fix? Bests. Carlos. > Issue with redeployment in Bndtools > --- > > Key: ARIES-1856 > URL: https://issues.apache.org/jira/browse/ARIES-1856 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.1 >Reporter: Timothy Ward >Assignee: Carlos Sierra >Priority: Major > > When using Bndtools for development there are many redeploys of the JAX-RS > whiteboard bundle (the bundle gets rebuilt on save). For some reason I am > seeing an NPE, after which my application is broken until I restart the > framework. > This is happening using the OSGi enRoute 7.0.0 templates. > > java.lang.NullPointerException: null > at > org.apache.aries.jax.rs.whiteboard.internal.utils.ServiceReferenceResourceProvider.getResourceClass(ServiceReferenceResourceProvider.java:56) > at > org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setResourceProviders(JAXRSServerFactoryBean.java:391) > at > org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setResourceProvider(JAXRSServerFactoryBean.java:381) > at > org.apache.aries.jax.rs.whiteboard.internal.cxf.CxfJaxrsServiceRegistrator.rewire(CxfJaxrsServiceRegistrator.java:282) > at > org.apache.aries.jax.rs.whiteboard.internal.cxf.CxfJaxrsServiceRegistrator.remove(CxfJaxrsServiceRegistrator.java:178) > at > org.apache.aries.jax.rs.whiteboard.internal.cxf.CxfJaxrsServiceRegistrator.add(CxfJaxrsServiceRegistrator.java:90) > at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:615) > at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:618) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28) > at org.apache.aries.component.dsl.OSGi.lambda$null$76(OSGi.java:710) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:25) > at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) > at java.util.Collections$2.tryAdvance(Collections.java:4717) > at java.util.Collections$2.forEachRemaining(Collections.java:4725) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) > at > org.apache.aries.component.dsl.internal.JustOSGiImpl.lambda$new$2(JustOSGiImpl.java:42) > at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50) > at org.apache.aries.component.dsl.OSGi.lambda$map$77(OSGi.java:710) > at > org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39) > at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50) > at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612) > at > org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39) > at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50) > at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612) > at > org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39) > at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50) > at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612) > at > org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39) > at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50) > at org.apache.aries.component.dsl.OSGi.lambda$null$73(OSGi.java:694) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28) > at org.apache.aries.component.dsl.OSGi.lambda$null$80(OSGi.java:735) > at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:618) > at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:618) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:25) > at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) > at java.util.Collections$2.tryAdvance(Collections.java:4717) > at java.util.Collections$2.forEachRemaining(Collections.java:4725) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at
[jira] [Assigned] (ARIES-1856) Issue with redeployment in Bndtools
[ https://issues.apache.org/jira/browse/ARIES-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra reassigned ARIES-1856: Assignee: Carlos Sierra > Issue with redeployment in Bndtools > --- > > Key: ARIES-1856 > URL: https://issues.apache.org/jira/browse/ARIES-1856 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.1 >Reporter: Timothy Ward >Assignee: Carlos Sierra >Priority: Major > > When using Bndtools for development there are many redeploys of the JAX-RS > whiteboard bundle (the bundle gets rebuilt on save). For some reason I am > seeing an NPE, after which my application is broken until I restart the > framework. > This is happening using the OSGi enRoute 7.0.0 templates. > > java.lang.NullPointerException: null > at > org.apache.aries.jax.rs.whiteboard.internal.utils.ServiceReferenceResourceProvider.getResourceClass(ServiceReferenceResourceProvider.java:56) > at > org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setResourceProviders(JAXRSServerFactoryBean.java:391) > at > org.apache.cxf.jaxrs.JAXRSServerFactoryBean.setResourceProvider(JAXRSServerFactoryBean.java:381) > at > org.apache.aries.jax.rs.whiteboard.internal.cxf.CxfJaxrsServiceRegistrator.rewire(CxfJaxrsServiceRegistrator.java:282) > at > org.apache.aries.jax.rs.whiteboard.internal.cxf.CxfJaxrsServiceRegistrator.remove(CxfJaxrsServiceRegistrator.java:178) > at > org.apache.aries.jax.rs.whiteboard.internal.cxf.CxfJaxrsServiceRegistrator.add(CxfJaxrsServiceRegistrator.java:90) > at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:615) > at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:618) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28) > at org.apache.aries.component.dsl.OSGi.lambda$null$76(OSGi.java:710) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:25) > at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) > at java.util.Collections$2.tryAdvance(Collections.java:4717) > at java.util.Collections$2.forEachRemaining(Collections.java:4725) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) > at > org.apache.aries.component.dsl.internal.JustOSGiImpl.lambda$new$2(JustOSGiImpl.java:42) > at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50) > at org.apache.aries.component.dsl.OSGi.lambda$map$77(OSGi.java:710) > at > org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39) > at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50) > at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612) > at > org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39) > at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50) > at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612) > at > org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39) > at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50) > at org.apache.aries.component.dsl.OSGi.lambda$effects$70(OSGi.java:612) > at > org.apache.aries.component.dsl.internal.OSGiImpl.lambda$create$0(OSGiImpl.java:39) > at org.apache.aries.component.dsl.internal.OSGiImpl.run(OSGiImpl.java:50) > at org.apache.aries.component.dsl.OSGi.lambda$null$73(OSGi.java:694) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28) > at org.apache.aries.component.dsl.OSGi.lambda$null$80(OSGi.java:735) > at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:618) > at org.apache.aries.component.dsl.OSGi.lambda$null$69(OSGi.java:618) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:28) > at org.apache.aries.component.dsl.Publisher.apply(Publisher.java:25) > at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193) > at java.util.Collections$2.tryAdvance(Collections.java:4717) > at java.util.Collections$2.forEachRemaining(Collections.java:4725) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) > at > java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) > at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > at
[jira] [Resolved] (ARIES-1852) Missing null check in PromiseAwareJAXRSInvoker
[
https://issues.apache.org/jira/browse/ARIES-1852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra resolved ARIES-1852.
--
Resolution: Fixed
> Missing null check in PromiseAwareJAXRSInvoker
> --
>
> Key: ARIES-1852
> URL: https://issues.apache.org/jira/browse/ARIES-1852
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.1
>Reporter: Carlos Sierra
>Assignee: Carlos Sierra
>Priority: Major
> Fix For: jax-rs-whiteboard-1.0.2
>
>
> Looks like {{Object result}} might be null and it is not being checked.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARIES-1852) Missing null check in PromiseAwareJAXRSInvoker
Carlos Sierra created ARIES-1852:
Summary: Missing null check in PromiseAwareJAXRSInvoker
Key: ARIES-1852
URL: https://issues.apache.org/jira/browse/ARIES-1852
Project: Aries
Issue Type: Bug
Components: jax-rs-whiteboard
Affects Versions: jax-rs-whiteboard-1.0.1
Reporter: Carlos Sierra
Assignee: Carlos Sierra
Fix For: jax-rs-whiteboard-1.0.2
Looks like {{Object result}} might be null and it is not being checked.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARIES-1842) CxfJaxRsServiceRegistrator might NPE when using service references of already unregistered services
[ https://issues.apache.org/jira/browse/ARIES-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra updated ARIES-1842: - Component/s: jax-rs-whiteboard > CxfJaxRsServiceRegistrator might NPE when using service references of already > unregistered services > --- > > Key: ARIES-1842 > URL: https://issues.apache.org/jira/browse/ARIES-1842 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.1 >Reporter: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.2 > > > or if the service factory returns null for whatever reason. > The whiteboard implementation should defend against this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ARIES-1843) JAX-RS Whiteboard is not handling _unregistering_ services
[ https://issues.apache.org/jira/browse/ARIES-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra reassigned ARIES-1843: Assignee: Carlos Sierra > JAX-RS Whiteboard is not handling _unregistering_ services > -- > > Key: ARIES-1843 > URL: https://issues.apache.org/jira/browse/ARIES-1843 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.1 >Reporter: Carlos Sierra >Assignee: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.2 > > > During service unregistration it can happen that the whiteboard refreshes the > application. This can lead to request a new instance of a service that is > being unregistered in that thread. This condition has to be explicitly > checked because, during this process, the service reference still appears as > registered. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARIES-1843) JAX-RS Whiteboard is not handling _unregistering_ services
[ https://issues.apache.org/jira/browse/ARIES-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra resolved ARIES-1843. -- Resolution: Fixed > JAX-RS Whiteboard is not handling _unregistering_ services > -- > > Key: ARIES-1843 > URL: https://issues.apache.org/jira/browse/ARIES-1843 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.1 >Reporter: Carlos Sierra >Assignee: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.2 > > > During service unregistration it can happen that the whiteboard refreshes the > application. This can lead to request a new instance of a service that is > being unregistered in that thread. This condition has to be explicitly > checked because, during this process, the service reference still appears as > registered. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARIES-1842) CxfJaxRsServiceRegistrator might NPE when using service references of already unregistered services
[ https://issues.apache.org/jira/browse/ARIES-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra resolved ARIES-1842. -- Resolution: Fixed Assignee: Carlos Sierra > CxfJaxRsServiceRegistrator might NPE when using service references of already > unregistered services > --- > > Key: ARIES-1842 > URL: https://issues.apache.org/jira/browse/ARIES-1842 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: jax-rs-whiteboard-1.0.1 >Reporter: Carlos Sierra >Assignee: Carlos Sierra >Priority: Major > Fix For: jax-rs-whiteboard-1.0.2 > > > or if the service factory returns null for whatever reason. > The whiteboard implementation should defend against this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARIES-1843) JAX-RS Whiteboard is not handling _unregistering_ services
Carlos Sierra created ARIES-1843: Summary: JAX-RS Whiteboard is not handling _unregistering_ services Key: ARIES-1843 URL: https://issues.apache.org/jira/browse/ARIES-1843 Project: Aries Issue Type: Bug Components: jax-rs-whiteboard Affects Versions: jax-rs-whiteboard-1.0.1 Reporter: Carlos Sierra Fix For: jax-rs-whiteboard-1.0.2 During service unregistration it can happen that the whiteboard refreshes the application. This can lead to request a new instance of a service that is being unregistered in that thread. This condition has to be explicitly checked because, during this process, the service reference still appears as registered. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARIES-1842) CxfJaxRsServiceRegistrator might NPE when using service references of already unregistered services
Carlos Sierra created ARIES-1842: Summary: CxfJaxRsServiceRegistrator might NPE when using service references of already unregistered services Key: ARIES-1842 URL: https://issues.apache.org/jira/browse/ARIES-1842 Project: Aries Issue Type: Bug Affects Versions: jax-rs-whiteboard-1.0.1 Reporter: Carlos Sierra Fix For: jax-rs-whiteboard-1.0.2 or if the service factory returns null for whatever reason. The whiteboard implementation should defend against this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ARIES-1798) Create a JIRA component for "Component DSL" project
[ https://issues.apache.org/jira/browse/ARIES-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra reassigned ARIES-1798: Assignee: Christian Schneider (was: Carlos Sierra) > Create a JIRA component for "Component DSL" project > --- > > Key: ARIES-1798 > URL: https://issues.apache.org/jira/browse/ARIES-1798 > Project: Aries > Issue Type: Request >Reporter: Raymond Augé >Assignee: Christian Schneider >Priority: Major > > *Component DSL* is a recent project developed by [~csierra]. > It recently released version 1.0.0. Congratz Carlos. > Sadly, as all projects realize, bugs are found and must be tracked. > Can we please create a Jira component for "Component DSL"? Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ARIES-1798) Create a JIRA component for "Component DSL" project
[ https://issues.apache.org/jira/browse/ARIES-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra reassigned ARIES-1798: Assignee: Carlos Sierra (was: Christian Schneider) > Create a JIRA component for "Component DSL" project > --- > > Key: ARIES-1798 > URL: https://issues.apache.org/jira/browse/ARIES-1798 > Project: Aries > Issue Type: Request >Reporter: Raymond Augé >Assignee: Carlos Sierra >Priority: Major > > *Component DSL* is a recent project developed by [~csierra]. > It recently released version 1.0.0. Congratz Carlos. > Sadly, as all projects realize, bugs are found and must be tracked. > Can we please create a Jira component for "Component DSL"? Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARIES-1832) NullPointerException in Configuration
[
https://issues.apache.org/jira/browse/ARIES-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra resolved ARIES-1832.
--
Resolution: Fixed
fixed in https://svn.apache.org/viewvc?view=revision=1840274
> NullPointerException in Configuration
> -
>
> Key: ARIES-1832
> URL: https://issues.apache.org/jira/browse/ARIES-1832
> Project: Aries
> Issue Type: Bug
> Components: Component DSL
>Affects Versions: component-dsl-1.2.0
>Reporter: Carlos Sierra
>Assignee: Carlos Sierra
>Priority: Minor
> Fix For: component-dsl-1.2.1
>
>
> {{ConfigurationOSGiImpl}} is not properly checking for the {{null}} returned
> value and is causing an unnecessary exception to be thrown and catched.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARIES-1832) NullPointerException in Configuration
Carlos Sierra created ARIES-1832:
Summary: NullPointerException in Configuration
Key: ARIES-1832
URL: https://issues.apache.org/jira/browse/ARIES-1832
Project: Aries
Issue Type: Bug
Components: Component DSL
Affects Versions: component-dsl-1.2.0
Reporter: Carlos Sierra
Assignee: Carlos Sierra
Fix For: component-dsl-1.2.1
{{ConfigurationOSGiImpl}} is not properly checking for the {{null}} returned
value and is causing an unnecessary exception to be thrown and catched.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ARIES-1831) Race condition when using accumulate
[
https://issues.apache.org/jira/browse/ARIES-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627491#comment-16627491
]
Carlos Sierra edited comment on ARIES-1831 at 9/25/18 3:20 PM:
---
Fixed in https://svn.apache.org/viewvc?view=revision=1837741
was (Author: csierra):
Fixed in 13af62fa7a2ab5aa25095da6ccf31d48e5df315e
> Race condition when using accumulate
>
>
> Key: ARIES-1831
> URL: https://issues.apache.org/jira/browse/ARIES-1831
> Project: Aries
> Issue Type: Bug
> Components: Component DSL
>Affects Versions: component-dsl-1.2.0
>Reporter: Carlos Sierra
>Assignee: Carlos Sierra
>Priority: Major
> Fix For: component-dsl-1.2.1
>
>
> {{OnlyLastPublisher}} was missing a synchronized block that made
> {{accumulate}} and {{accumulateInMap}} be subject of race condition errors.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARIES-1831) Race condition when using accumulate
[
https://issues.apache.org/jira/browse/ARIES-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra resolved ARIES-1831.
--
Resolution: Fixed
Fixed in 13af62fa7a2ab5aa25095da6ccf31d48e5df315e
> Race condition when using accumulate
>
>
> Key: ARIES-1831
> URL: https://issues.apache.org/jira/browse/ARIES-1831
> Project: Aries
> Issue Type: Bug
> Components: Component DSL
>Affects Versions: component-dsl-1.2.0
>Reporter: Carlos Sierra
>Assignee: Carlos Sierra
>Priority: Major
> Fix For: component-dsl-1.2.1
>
>
> {{OnlyLastPublisher}} was missing a synchronized block that made
> {{accumulate}} and {{accumulateInMap}} be subject of race condition errors.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARIES-1831) Race condition when using accumulate
Carlos Sierra created ARIES-1831:
Summary: Race condition when using accumulate
Key: ARIES-1831
URL: https://issues.apache.org/jira/browse/ARIES-1831
Project: Aries
Issue Type: Bug
Components: Component DSL
Affects Versions: component-dsl-1.2.0
Reporter: Carlos Sierra
Assignee: Carlos Sierra
Fix For: component-dsl-1.2.1
{{OnlyLastPublisher}} was missing a synchronized block that made {{accumulate}}
and {{accumulateInMap}} be subject of race condition errors.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (ARIES-1827) Add application base prefix for the whole whiteboard
[ https://issues.apache.org/jira/browse/ARIES-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra closed ARIES-1827. > Add application base prefix for the whole whiteboard > > > Key: ARIES-1827 > URL: https://issues.apache.org/jira/browse/ARIES-1827 > Project: Aries > Issue Type: New Feature > Components: jax-rs-whiteboard >Affects Versions: 1.0 >Reporter: Carlos Sierra >Priority: Minor > Fix For: 1.0.1 > > > Allow to specify a property to a whiteboard to prepend a path to all the > applications deployed in it -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARIES-1830) Support OSGi promises as asychronous return types in the jaxrs whiteboard
[ https://issues.apache.org/jira/browse/ARIES-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra closed ARIES-1830. Resolution: Done > Support OSGi promises as asychronous return types in the jaxrs whiteboard > - > > Key: ARIES-1830 > URL: https://issues.apache.org/jira/browse/ARIES-1830 > Project: Aries > Issue Type: New Feature > Components: jax-rs-whiteboard >Reporter: Carlos Sierra >Priority: Minor > Fix For: 1.0.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARIES-1830) Support OSGi promises as asychronous return types in the jaxrs whiteboard
Carlos Sierra created ARIES-1830: Summary: Support OSGi promises as asychronous return types in the jaxrs whiteboard Key: ARIES-1830 URL: https://issues.apache.org/jira/browse/ARIES-1830 Project: Aries Issue Type: New Feature Components: jax-rs-whiteboard Reporter: Carlos Sierra Fix For: 1.0.1 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARIES-1827) Add application base prefix for the whole whiteboard
[ https://issues.apache.org/jira/browse/ARIES-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra resolved ARIES-1827. -- Resolution: Fixed > Add application base prefix for the whole whiteboard > > > Key: ARIES-1827 > URL: https://issues.apache.org/jira/browse/ARIES-1827 > Project: Aries > Issue Type: New Feature > Components: jax-rs-whiteboard >Affects Versions: 1.0 >Reporter: Carlos Sierra >Priority: Minor > Fix For: 1.0.1 > > > Allow to specify a property to a whiteboard to prepend a path to all the > applications deployed in it -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARIES-1828) JAX-RS whiteboard is registering the JaxRsServiceRuntime interface before it is ready
[ https://issues.apache.org/jira/browse/ARIES-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sierra closed ARIES-1828. Resolution: Not A Problem After some discussion it looks like this is not a problem because the runtime service registration is further updated with the processed services and that can be used to detect the activity. > JAX-RS whiteboard is registering the JaxRsServiceRuntime interface before it > is ready > - > > Key: ARIES-1828 > URL: https://issues.apache.org/jira/browse/ARIES-1828 > Project: Aries > Issue Type: Bug > Components: jax-rs-whiteboard >Affects Versions: 1.0 >Reporter: Carlos Sierra >Priority: Major > Fix For: 1.0.1 > > > The whiteboard implementation is registering the JaxRsServiceRuntime before > it is ready to process services, which makes more difficult to test or to > synch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARIES-1827) Add application base prefix for the whole whiteboard
Carlos Sierra created ARIES-1827: Summary: Add application base prefix for the whole whiteboard Key: ARIES-1827 URL: https://issues.apache.org/jira/browse/ARIES-1827 Project: Aries Issue Type: New Feature Components: jax-rs-whiteboard Affects Versions: 1.0 Reporter: Carlos Sierra Fix For: 1.0.1 Allow to specify a property to a whiteboard to prepend a path to all the applications deployed in it -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARIES-1828) JAX-RS whiteboard is registering the JaxRsServiceRuntime interface before it is ready
Carlos Sierra created ARIES-1828: Summary: JAX-RS whiteboard is registering the JaxRsServiceRuntime interface before it is ready Key: ARIES-1828 URL: https://issues.apache.org/jira/browse/ARIES-1828 Project: Aries Issue Type: Bug Components: jax-rs-whiteboard Affects Versions: 1.0 Reporter: Carlos Sierra Fix For: 1.0.1 The whiteboard implementation is registering the JaxRsServiceRuntime before it is ready to process services, which makes more difficult to test or to synch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARIES-1784) @Component without (service=A.class) end in Nullpointer
[
https://issues.apache.org/jira/browse/ARIES-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559722#comment-16559722
]
Carlos Sierra commented on ARIES-1784:
--
sure... in my first comment I should have specified the specification... :-)
> @Component without (service=A.class) end in Nullpointer
> ---
>
> Key: ARIES-1784
> URL: https://issues.apache.org/jira/browse/ARIES-1784
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.0
>Reporter: Stefan Bischof
>Priority: Major
>
> Hi,
> when i hava a Ressource annotated with @Component but without
> (service=A.class) and call AriesJaxrsServiceRuntime.getRuntimeDTO i get a in
> Nullpointer
> org.apache.aries.jax.rs.whiteboard.internal.CxfJaxrsServiceRegistrator.getStaticResourceC
> lasses(CxfJaxrsServiceRegistrator.java:307
> Stacktrace:
> Feb 20, 2018 1:50:50 PM org.apache.cxf.phase.PhaseInterceptorChain
> doDefaultLogging
> WARNUNG: Application
> {openapi.rsw.hub.domain.org/}
> OpenApiResource has thrown
> exception, unwinding now
> org.apache.cxf.interceptor.Fault
> at
>
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162)
> at
>
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:192)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:103)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java
> :59)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerIntercep
> tor.java:96)
> at
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:1
> 21)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java
> :267)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.ja
> va:234)
> at
>
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
>
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:191)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.ja
> va:301)
> at
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:225)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276
> )
> at
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:85)
> at
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.jav
> a:79)
> at
>
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:128)
> at
> org.apache.felix.http.base.internal.dispatch.DispatcherServlet.service(DispatcherServlet.
> java:49)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:848)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584)
> at
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
> at
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection
> .java:213)
> at
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:534)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:28
> 3)
> at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:108)
> at
>
> org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93)
> at
> org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(Execut
> eProduceConsume.java:303)
> at
>
[jira] [Commented] (ARIES-1784) @Component without (service=A.class) end in Nullpointer
[
https://issues.apache.org/jira/browse/ARIES-1784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559709#comment-16559709
]
Carlos Sierra commented on ARIES-1784:
--
Hey [~jalbert],
it is in the JAX-RS 2.1 specification, Section 2.1:
{{The resources and providers that make up a JAX-RS application are configured
via an application-supplied subclass of Application. An implementation MAY
provide alternate mechanisms for locating resource classes and providers (e.g.
runtime class scanning) but use of Application is the only portable means of
configuration.}}
The whiteboard is just handling the provided service to the JAX-RS
implementation, CXF in this case.
Carlos.
> @Component without (service=A.class) end in Nullpointer
> ---
>
> Key: ARIES-1784
> URL: https://issues.apache.org/jira/browse/ARIES-1784
> Project: Aries
> Issue Type: Bug
> Components: jax-rs-whiteboard
>Affects Versions: jax-rs-whiteboard-1.0.0
>Reporter: Stefan Bischof
>Priority: Major
>
> Hi,
> when i hava a Ressource annotated with @Component but without
> (service=A.class) and call AriesJaxrsServiceRuntime.getRuntimeDTO i get a in
> Nullpointer
> org.apache.aries.jax.rs.whiteboard.internal.CxfJaxrsServiceRegistrator.getStaticResourceC
> lasses(CxfJaxrsServiceRegistrator.java:307
> Stacktrace:
> Feb 20, 2018 1:50:50 PM org.apache.cxf.phase.PhaseInterceptorChain
> doDefaultLogging
> WARNUNG: Application
> {openapi.rsw.hub.domain.org/}
> OpenApiResource has thrown
> exception, unwinding now
> org.apache.cxf.interceptor.Fault
> at
>
> org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:162)
> at
>
> org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:128)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:192)
> at org.apache.cxf.jaxrs.JAXRSInvoker.invoke(JAXRSInvoker.java:103)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java
> :59)
> at
> org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerIntercep
> tor.java:96)
> at
>
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
> at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:1
> 21)
> at
> org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java
> :267)
> at
> org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.ja
> va:234)
> at
>
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
> at
>
> org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
> at
> org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:191)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.ja
> va:301)
> at
>
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.doGet(AbstractHTTPServlet.java:225)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
> at
> org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:276
> )
> at
> org.apache.felix.http.base.internal.handler.ServletHandler.handle(ServletHandler.java:85)
> at
> org.apache.felix.http.base.internal.dispatch.InvocationChain.doFilter(InvocationChain.jav
> a:79)
> at
>
> org.apache.felix.http.base.internal.dispatch.Dispatcher.dispatch(Dispatcher.java:128)
> at
> org.apache.felix.http.base.internal.dispatch.DispatcherServlet.service(DispatcherServlet.
> java:49)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:848)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:584)
> at
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:224)
> at
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1180)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:512)
> at
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
> at
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1112)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection
> .java:213)
> at
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:134)
> at org.eclipse.jetty.server.Server.handle(Server.java:534)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
> at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
[jira] [Created] (ARIES-1821) JAX-RS Whiteboard is not using prototype scope when registering services for HTTP Whiteboard
Carlos Sierra created ARIES-1821: Summary: JAX-RS Whiteboard is not using prototype scope when registering services for HTTP Whiteboard Key: ARIES-1821 URL: https://issues.apache.org/jira/browse/ARIES-1821 Project: Aries Issue Type: Bug Components: jax-rs-whiteboard Affects Versions: jax-rs-whiteboard-1.0.0 Reporter: Carlos Sierra Http Whiteboard recommends using prototype scope for servlets and filters to avoid calling destroy and init on instances that might not support it. Currently singleton scope is used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARIES-1810) `onClose` does not execute the action in the correct order
[
https://issues.apache.org/jira/browse/ARIES-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra resolved ARIES-1810.
--
Resolution: Fixed
Fix Version/s: component-dsl-1.2.0
> `onClose` does not execute the action in the correct order
> --
>
> Key: ARIES-1810
> URL: https://issues.apache.org/jira/browse/ARIES-1810
> Project: Aries
> Issue Type: Bug
> Components: Component DSL
>Affects Versions: component-dsl-1.1.0
>Reporter: Carlos Sierra
>Priority: Major
> Fix For: component-dsl-1.2.0
>
>
> It executed the _on leave_ action in the opposite order to {{effects}} which
> creates inconsistencies.
> Actually onClose should be deprecated in favor of effects
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARIES-1812) `once` should support updates
[
https://issues.apache.org/jira/browse/ARIES-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra resolved ARIES-1812.
--
Resolution: Fixed
Fix Version/s: component-dsl-1.2.0
> `once` should support updates
> -
>
> Key: ARIES-1812
> URL: https://issues.apache.org/jira/browse/ARIES-1812
> Project: Aries
> Issue Type: Bug
> Components: Component DSL
>Affects Versions: component-dsl-1.1.0
>Reporter: Carlos Sierra
>Priority: Minor
> Fix For: component-dsl-1.2.0
>
>
> {{once}} is normally used to test the existance of a given service or
> configuration with certain properties. When there is only one tracked
> instance and that instance is updated, {{once}} will retract the program
> associated to the instance and publish the instance again. This is usually
> unnecessary and {{once}} should support update operations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARIES-1811) `effects` is not unwinding properly when exceptions occur
[
https://issues.apache.org/jira/browse/ARIES-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra resolved ARIES-1811.
--
Resolution: Fixed
Fix Version/s: component-dsl-1.2.0
> `effects` is not unwinding properly when exceptions occur
> -
>
> Key: ARIES-1811
> URL: https://issues.apache.org/jira/browse/ARIES-1811
> Project: Aries
> Issue Type: Bug
> Components: Component DSL
>Affects Versions: component-dsl-1.1.0
>Reporter: Carlos Sierra
>Priority: Major
> Fix For: component-dsl-1.2.0
>
>
> {{effects}} does not execute the _on leave_ action if an exception occur.
> This can leave the system in an inconsistent state, event if {{recover}} or
> {{recoverWith}} have been correctly used.
> It should make sure the _on leave_ action is always executed *if and only if*
> the _on adding_ action has been executed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARIES-1813) `effects` must allow more effect execution points
[
https://issues.apache.org/jira/browse/ARIES-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sierra resolved ARIES-1813.
--
Resolution: Fixed
Fix Version/s: component-dsl-1.2.0
> `effects` must allow more effect execution points
> -
>
> Key: ARIES-1813
> URL: https://issues.apache.org/jira/browse/ARIES-1813
> Project: Aries
> Issue Type: Bug
> Components: Component DSL
>Affects Versions: component-dsl-1.1.0
>Reporter: Carlos Sierra
>Priority: Major
> Fix For: component-dsl-1.2.0
>
>
> There are two events that DSL nodes must handle: a new instance arrives and
> an instance leaves. For both these two events there exist two possible
> effects execution points: before and after, just like an aspect.
> {{effects}} must allow to specify all four execution points, although this
> has implications with error handling since not every execution point has the
> same impact in the execution of the program.
> For simplicity the two parameter {{effects}} will remain and will mean
> correspond to {{before adding}} and {{after removal}}. Any other combination
> must be specified with the four parameter version.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
