[GitHub] cxf issue #181: ensuring CDI Bean are always the CDI context ones

[rmannibucau]

Github user rmannibucau commented on the issue:

https://github.com/apache/cxf/pull/181
  
@johnament updated and removed the null

retest this please ?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cxf pull request #182: [CXF-6986] If no application classes found, install a...

[johnament]

GitHub user johnament opened a pull request:

https://github.com/apache/cxf/pull/182

[CXF-6986] If no application classes found, install a default application

Some minor clean ups like make sure on the latest weld version.

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

$ git pull https://github.com/johnament/cxf CXF-6986

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

https://github.com/apache/cxf/pull/182.patch

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

This closes #182


commit e8c6c6a8ddbc2c2d5142c5f85728cc4358342ddb
Author: John D. Ament 
Date:   2016-08-03T00:34:08Z

[CXF-6986] If no application classes found, install a default application.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cxf issue #181: ensuring CDI Bean are always the CDI context ones

[johnament]

Github user johnament commented on the issue:

https://github.com/apache/cxf/pull/181
  
The CDI failures are concerning.  The CC must be provided.  can you revert 
that part of the change? Or does it break something in OWB?

Probably should also commit under the JIRA ticket.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: cxi integration: multiple buses during deployment?

[Romain Manni-Bucau]

here it is https://github.com/apache/cxf/pull/181


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-10-19 20:28 GMT+02:00 John D. Ament :

> Could you raise a PR against 3.1.x?  This way the PR builder runs and can
> test that there's no regression w/ Weld.
>
> John
>
> On Wed, Oct 19, 2016 at 2:03 PM Romain Manni-Bucau 
> wrote:
>
> > in the meantime if someone can apply my patch or equivalent and push a
> > 3.1.9-SNAPSHOT it would unblock us.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Wordpress Blog
> >  | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn  | Tomitriber
> >  | JavaEE Factory
> > 
> >
> > 2016-10-19 19:48 GMT+02:00 John D. Ament :
> >
> > > Yep I remember mark mentioned that to me before.  Ok I need to
> prioritize
> > > getting those extra tests too.
> > >
> > > On Oct 19, 2016 13:29, "Romain Manni-Bucau" 
> > wrote:
> > >
> > > > @John: yes, didn't check weld but OWB wraps 3rd party Bean (cxf
> bus
> > > > here) where weld doesn't probably.
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Wordpress Blog
> > > >  | Github  > > > rmannibucau> |
> > > > LinkedIn  | Tomitriber
> > > >  | JavaEE Factory
> > > > 
> > > >
> > > > 2016-10-19 19:19 GMT+02:00 John D. Ament :
> > > >
> > > > > Ok this makes sense now.  I suspect this is an internal diff
> between
> > > owb
> > > > > and weld (hence why i still want those tests).  Thanks Roma!
> > > > >
> > > > > On Oct 19, 2016 13:16, "Romain Manni-Bucau"  >
> > > > wrote:
> > > > >
> > > > > > http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk/
> just
> > > run
> > > > > > core
> > > > > > module
> > > > > >
> > > > > > Think the extension was written with Weld which behaves a bit
> > > > differently
> > > > > > from openwebbeans on that point.
> > > > > >
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau  |  Blog
> > > > > >  | Old Wordpress Blog
> > > > > >  | Github  > > > > > rmannibucau> |
> > > > > > LinkedIn  | Tomitriber
> > > > > >  | JavaEE Factory
> > > > > > 
> > > > > >
> > > > > > 2016-10-19 19:08 GMT+02:00 Andrey Redko :
> > > > > >
> > > > > > > Hey Roman,
> > > > > > >
> > > > > > > Thanks a lot for verifying. Would you mind to share the sample
> > > > project
> > > > > to
> > > > > > > reproduce the issue?
> > > > > > > There seems to be more things to take into account.
> > > > > > > Thanks.
> > > > > > >
> > > > > > > Best Regards,
> > > > > > > Andriy Redko
> > > > > > >
> > > > > > > On Wed, Oct 19, 2016 at 9:24 AM, Romain Manni-Bucau <
> > > > > > rmannibu...@gmail.com
> > > > > > > > wrote:
> > > > > > >
> > > > > > >> doesn't work but for a weirder reason.
> > > > > > >>
> > > > > > >> CdiBean is added programmatically - all fine
> > > > > > >>
> > > > > > >> Then it is directly used to get the bus (in "use the default
> > bus"
> > > > > mode).
> > > > > > >> This is not really fine since the CDI impl is free to wrap
> this
> > so
> > > > you
> > > > > > >> should retrieve the actual instance of the bus and get it with
> > > this
> > > > > Bean
> > > > > > >> instance and not supposing the CDI container will return you
> the
> > > > > > instance
> > > > > > >> you added.
> > > > > > >>
> > > > > > >> Concretely here are the few fixes (on 3.1.x-fixes branch):
> > > > > > >> https://gist.github.com/rmannibucau/
> > > 0bb8abf2e164d953be17b24b4a08e6
> > > > 85
> > > > > > >>
> > > > > > >> In CDI you can't assume equals/hashcode of Bean so you need
> > to
> > > > > lookup
> > > > > > >> the bus instance and not use the internal one. This patch
> solves
> > > the
> > > > > > issue.
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> Romain Manni-Bucau
> > > > > > >> @rmannibucau  |  Blog
> > > > > > >>  | Old Wordpress Blog
> > > > > > >>  | Github
> > > > > > >> 

[GitHub] cxf pull request #181: ensuring CDI Bean are always the CDI context ones

[rmannibucau]

GitHub user rmannibucau opened a pull request:

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

ensuring CDI Bean are always the CDI context ones



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

$ git pull https://github.com/rmannibucau/cxf fb/3.1.x-cdi-fixes

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

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

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

This closes #181


commit de579f50b170eb584208fd7aa84e934d573df248
Author: rmannibucau 
Date:   2016-10-19T19:40:01Z

ensuring CDI Bean are always the CDI context ones




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: cxi integration: multiple buses during deployment?

[John D. Ament]

Could you raise a PR against 3.1.x?  This way the PR builder runs and can
test that there's no regression w/ Weld.

John

On Wed, Oct 19, 2016 at 2:03 PM Romain Manni-Bucau 
wrote:

> in the meantime if someone can apply my patch or equivalent and push a
> 3.1.9-SNAPSHOT it would unblock us.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Tomitriber
>  | JavaEE Factory
> 
>
> 2016-10-19 19:48 GMT+02:00 John D. Ament :
>
> > Yep I remember mark mentioned that to me before.  Ok I need to prioritize
> > getting those extra tests too.
> >
> > On Oct 19, 2016 13:29, "Romain Manni-Bucau" 
> wrote:
> >
> > > @John: yes, didn't check weld but OWB wraps 3rd party Bean (cxf bus
> > > here) where weld doesn't probably.
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Wordpress Blog
> > >  | Github  > > rmannibucau> |
> > > LinkedIn  | Tomitriber
> > >  | JavaEE Factory
> > > 
> > >
> > > 2016-10-19 19:19 GMT+02:00 John D. Ament :
> > >
> > > > Ok this makes sense now.  I suspect this is an internal diff between
> > owb
> > > > and weld (hence why i still want those tests).  Thanks Roma!
> > > >
> > > > On Oct 19, 2016 13:16, "Romain Manni-Bucau" 
> > > wrote:
> > > >
> > > > > http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk/ just
> > run
> > > > > core
> > > > > module
> > > > >
> > > > > Think the extension was written with Weld which behaves a bit
> > > differently
> > > > > from openwebbeans on that point.
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Old Wordpress Blog
> > > > >  | Github  > > > > rmannibucau> |
> > > > > LinkedIn  | Tomitriber
> > > > >  | JavaEE Factory
> > > > > 
> > > > >
> > > > > 2016-10-19 19:08 GMT+02:00 Andrey Redko :
> > > > >
> > > > > > Hey Roman,
> > > > > >
> > > > > > Thanks a lot for verifying. Would you mind to share the sample
> > > project
> > > > to
> > > > > > reproduce the issue?
> > > > > > There seems to be more things to take into account.
> > > > > > Thanks.
> > > > > >
> > > > > > Best Regards,
> > > > > > Andriy Redko
> > > > > >
> > > > > > On Wed, Oct 19, 2016 at 9:24 AM, Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com
> > > > > > > wrote:
> > > > > >
> > > > > >> doesn't work but for a weirder reason.
> > > > > >>
> > > > > >> CdiBean is added programmatically - all fine
> > > > > >>
> > > > > >> Then it is directly used to get the bus (in "use the default
> bus"
> > > > mode).
> > > > > >> This is not really fine since the CDI impl is free to wrap this
> so
> > > you
> > > > > >> should retrieve the actual instance of the bus and get it with
> > this
> > > > Bean
> > > > > >> instance and not supposing the CDI container will return you the
> > > > > instance
> > > > > >> you added.
> > > > > >>
> > > > > >> Concretely here are the few fixes (on 3.1.x-fixes branch):
> > > > > >> https://gist.github.com/rmannibucau/
> > 0bb8abf2e164d953be17b24b4a08e6
> > > 85
> > > > > >>
> > > > > >> In CDI you can't assume equals/hashcode of Bean so you need
> to
> > > > lookup
> > > > > >> the bus instance and not use the internal one. This patch solves
> > the
> > > > > issue.
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> Romain Manni-Bucau
> > > > > >> @rmannibucau  |  Blog
> > > > > >>  | Old Wordpress Blog
> > > > > >>  | Github
> > > > > >>  | LinkedIn
> > > > > >>  | Tomitriber
> > > > > >>  | JavaEE Factory
> > > > > >> 
> > > > > >>
> > > > > >> 2016-10-19 13:35 GMT+02:00 Andrey Redko :
> > > > > >>
> > > > > >>> Hi Roman,
> > > > > >>>
> > > > > >>> Thanks a lot for clarifying on things. Could you please try
> > latest
> > > > > >>> 3.1.9-SNAPSHOT / 3.2.0-SNAPSHOT against this issue?
> > > > > >>> The fix should be there. Thanks!
> > > > > >>>
> > > > > >>> Best Regards,
> > > > > >>> Andriy Redko
> > > > > >>>
> > > > > >>> On Wed, Oct 19, 2016 at 2:28 AM, Romain Manni-Bucau <
> > > > > >>> rmannibu...@gmail.com> wrot

[GitHub] cxf pull request #150: [CXF-6986] If no application classes found, install a...

[johnament]

Github user johnament closed the pull request at:

https://github.com/apache/cxf/pull/150


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: cxi integration: multiple buses during deployment?

[Romain Manni-Bucau]

in the meantime if someone can apply my patch or equivalent and push a
3.1.9-SNAPSHOT it would unblock us.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-10-19 19:48 GMT+02:00 John D. Ament :

> Yep I remember mark mentioned that to me before.  Ok I need to prioritize
> getting those extra tests too.
>
> On Oct 19, 2016 13:29, "Romain Manni-Bucau"  wrote:
>
> > @John: yes, didn't check weld but OWB wraps 3rd party Bean (cxf bus
> > here) where weld doesn't probably.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Wordpress Blog
> >  | Github  > rmannibucau> |
> > LinkedIn  | Tomitriber
> >  | JavaEE Factory
> > 
> >
> > 2016-10-19 19:19 GMT+02:00 John D. Ament :
> >
> > > Ok this makes sense now.  I suspect this is an internal diff between
> owb
> > > and weld (hence why i still want those tests).  Thanks Roma!
> > >
> > > On Oct 19, 2016 13:16, "Romain Manni-Bucau" 
> > wrote:
> > >
> > > > http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk/ just
> run
> > > > core
> > > > module
> > > >
> > > > Think the extension was written with Weld which behaves a bit
> > differently
> > > > from openwebbeans on that point.
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Old Wordpress Blog
> > > >  | Github  > > > rmannibucau> |
> > > > LinkedIn  | Tomitriber
> > > >  | JavaEE Factory
> > > > 
> > > >
> > > > 2016-10-19 19:08 GMT+02:00 Andrey Redko :
> > > >
> > > > > Hey Roman,
> > > > >
> > > > > Thanks a lot for verifying. Would you mind to share the sample
> > project
> > > to
> > > > > reproduce the issue?
> > > > > There seems to be more things to take into account.
> > > > > Thanks.
> > > > >
> > > > > Best Regards,
> > > > > Andriy Redko
> > > > >
> > > > > On Wed, Oct 19, 2016 at 9:24 AM, Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > > wrote:
> > > > >
> > > > >> doesn't work but for a weirder reason.
> > > > >>
> > > > >> CdiBean is added programmatically - all fine
> > > > >>
> > > > >> Then it is directly used to get the bus (in "use the default bus"
> > > mode).
> > > > >> This is not really fine since the CDI impl is free to wrap this so
> > you
> > > > >> should retrieve the actual instance of the bus and get it with
> this
> > > Bean
> > > > >> instance and not supposing the CDI container will return you the
> > > > instance
> > > > >> you added.
> > > > >>
> > > > >> Concretely here are the few fixes (on 3.1.x-fixes branch):
> > > > >> https://gist.github.com/rmannibucau/
> 0bb8abf2e164d953be17b24b4a08e6
> > 85
> > > > >>
> > > > >> In CDI you can't assume equals/hashcode of Bean so you need to
> > > lookup
> > > > >> the bus instance and not use the internal one. This patch solves
> the
> > > > issue.
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> Romain Manni-Bucau
> > > > >> @rmannibucau  |  Blog
> > > > >>  | Old Wordpress Blog
> > > > >>  | Github
> > > > >>  | LinkedIn
> > > > >>  | Tomitriber
> > > > >>  | JavaEE Factory
> > > > >> 
> > > > >>
> > > > >> 2016-10-19 13:35 GMT+02:00 Andrey Redko :
> > > > >>
> > > > >>> Hi Roman,
> > > > >>>
> > > > >>> Thanks a lot for clarifying on things. Could you please try
> latest
> > > > >>> 3.1.9-SNAPSHOT / 3.2.0-SNAPSHOT against this issue?
> > > > >>> The fix should be there. Thanks!
> > > > >>>
> > > > >>> Best Regards,
> > > > >>> Andriy Redko
> > > > >>>
> > > > >>> On Wed, Oct 19, 2016 at 2:28 AM, Romain Manni-Bucau <
> > > > >>> rmannibu...@gmail.com> wrote:
> > > > >>>
> > > >  Le 19 oct. 2016 04:14, "Andriy Redko"  a
> écrit
> > :
> > > >  >
> > > >  > I think this is what is happening:
> > > >  >  - Roman defines own CXF bus bean, named "cxf"
> > > > 
> > > >  This is a workaround to be able to lookup the bus in my
> workaround
> > > >  extension. Not doing it without my extension leads to the issue.
> > > > 
> > > >  >  - our JAX-RS CDI extension finds it and

Re: cxi integration: multiple buses during deployment?

[John D. Ament]

Yep I remember mark mentioned that to me before.  Ok I need to prioritize
getting those extra tests too.

On Oct 19, 2016 13:29, "Romain Manni-Bucau"  wrote:

> @John: yes, didn't check weld but OWB wraps 3rd party Bean (cxf bus
> here) where weld doesn't probably.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github  rmannibucau> |
> LinkedIn  | Tomitriber
>  | JavaEE Factory
> 
>
> 2016-10-19 19:19 GMT+02:00 John D. Ament :
>
> > Ok this makes sense now.  I suspect this is an internal diff between owb
> > and weld (hence why i still want those tests).  Thanks Roma!
> >
> > On Oct 19, 2016 13:16, "Romain Manni-Bucau" 
> wrote:
> >
> > > http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk/ just run
> > > core
> > > module
> > >
> > > Think the extension was written with Weld which behaves a bit
> differently
> > > from openwebbeans on that point.
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Old Wordpress Blog
> > >  | Github  > > rmannibucau> |
> > > LinkedIn  | Tomitriber
> > >  | JavaEE Factory
> > > 
> > >
> > > 2016-10-19 19:08 GMT+02:00 Andrey Redko :
> > >
> > > > Hey Roman,
> > > >
> > > > Thanks a lot for verifying. Would you mind to share the sample
> project
> > to
> > > > reproduce the issue?
> > > > There seems to be more things to take into account.
> > > > Thanks.
> > > >
> > > > Best Regards,
> > > > Andriy Redko
> > > >
> > > > On Wed, Oct 19, 2016 at 9:24 AM, Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > > wrote:
> > > >
> > > >> doesn't work but for a weirder reason.
> > > >>
> > > >> CdiBean is added programmatically - all fine
> > > >>
> > > >> Then it is directly used to get the bus (in "use the default bus"
> > mode).
> > > >> This is not really fine since the CDI impl is free to wrap this so
> you
> > > >> should retrieve the actual instance of the bus and get it with this
> > Bean
> > > >> instance and not supposing the CDI container will return you the
> > > instance
> > > >> you added.
> > > >>
> > > >> Concretely here are the few fixes (on 3.1.x-fixes branch):
> > > >> https://gist.github.com/rmannibucau/0bb8abf2e164d953be17b24b4a08e6
> 85
> > > >>
> > > >> In CDI you can't assume equals/hashcode of Bean so you need to
> > lookup
> > > >> the bus instance and not use the internal one. This patch solves the
> > > issue.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> Romain Manni-Bucau
> > > >> @rmannibucau  |  Blog
> > > >>  | Old Wordpress Blog
> > > >>  | Github
> > > >>  | LinkedIn
> > > >>  | Tomitriber
> > > >>  | JavaEE Factory
> > > >> 
> > > >>
> > > >> 2016-10-19 13:35 GMT+02:00 Andrey Redko :
> > > >>
> > > >>> Hi Roman,
> > > >>>
> > > >>> Thanks a lot for clarifying on things. Could you please try latest
> > > >>> 3.1.9-SNAPSHOT / 3.2.0-SNAPSHOT against this issue?
> > > >>> The fix should be there. Thanks!
> > > >>>
> > > >>> Best Regards,
> > > >>> Andriy Redko
> > > >>>
> > > >>> On Wed, Oct 19, 2016 at 2:28 AM, Romain Manni-Bucau <
> > > >>> rmannibu...@gmail.com> wrote:
> > > >>>
> > >  Le 19 oct. 2016 04:14, "Andriy Redko"  a écrit
> :
> > >  >
> > >  > I think this is what is happening:
> > >  >  - Roman defines own CXF bus bean, named "cxf"
> > > 
> > >  This is a workaround to be able to lookup the bus in my workaround
> > >  extension. Not doing it without my extension leads to the issue.
> > > 
> > >  >  - our JAX-RS CDI extension finds it and makes it a "default"
> bus
> > to
> > >  be used
> > >  >for JAXRSServerFactoryBean instances
> > >  >  - however, JAXRSServerFactoryBean::setApplication() would
> > create a
> > >  new bus
> > >  >nonetheless, because the actual call to
> > >  JAXRSServerFactoryBean::setBus would
> > >  >be done later
> > >  >
> > > 
> > >  This is the issue, custom bus or not.
> > > 
> > >  > The issue in this case is that application was created using one
> > bus
> > >  instance,
> > >  > but JAXRSServerFactoryBean would be initialized using another
> bus
> > >  instance. This
> > >  > is my understading of the problem. Hopefully it makes sense.
> > >  >
> > > 
> > >  The factory uses the cdi bus b

Re: cxi integration: multiple buses during deployment?

[Romain Manni-Bucau]

@John: yes, didn't check weld but OWB wraps 3rd party Bean (cxf bus
here) where weld doesn't probably.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-10-19 19:19 GMT+02:00 John D. Ament :

> Ok this makes sense now.  I suspect this is an internal diff between owb
> and weld (hence why i still want those tests).  Thanks Roma!
>
> On Oct 19, 2016 13:16, "Romain Manni-Bucau"  wrote:
>
> > http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk/ just run
> > core
> > module
> >
> > Think the extension was written with Weld which behaves a bit differently
> > from openwebbeans on that point.
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Wordpress Blog
> >  | Github  > rmannibucau> |
> > LinkedIn  | Tomitriber
> >  | JavaEE Factory
> > 
> >
> > 2016-10-19 19:08 GMT+02:00 Andrey Redko :
> >
> > > Hey Roman,
> > >
> > > Thanks a lot for verifying. Would you mind to share the sample project
> to
> > > reproduce the issue?
> > > There seems to be more things to take into account.
> > > Thanks.
> > >
> > > Best Regards,
> > > Andriy Redko
> > >
> > > On Wed, Oct 19, 2016 at 9:24 AM, Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > > wrote:
> > >
> > >> doesn't work but for a weirder reason.
> > >>
> > >> CdiBean is added programmatically - all fine
> > >>
> > >> Then it is directly used to get the bus (in "use the default bus"
> mode).
> > >> This is not really fine since the CDI impl is free to wrap this so you
> > >> should retrieve the actual instance of the bus and get it with this
> Bean
> > >> instance and not supposing the CDI container will return you the
> > instance
> > >> you added.
> > >>
> > >> Concretely here are the few fixes (on 3.1.x-fixes branch):
> > >> https://gist.github.com/rmannibucau/0bb8abf2e164d953be17b24b4a08e685
> > >>
> > >> In CDI you can't assume equals/hashcode of Bean so you need to
> lookup
> > >> the bus instance and not use the internal one. This patch solves the
> > issue.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Romain Manni-Bucau
> > >> @rmannibucau  |  Blog
> > >>  | Old Wordpress Blog
> > >>  | Github
> > >>  | LinkedIn
> > >>  | Tomitriber
> > >>  | JavaEE Factory
> > >> 
> > >>
> > >> 2016-10-19 13:35 GMT+02:00 Andrey Redko :
> > >>
> > >>> Hi Roman,
> > >>>
> > >>> Thanks a lot for clarifying on things. Could you please try latest
> > >>> 3.1.9-SNAPSHOT / 3.2.0-SNAPSHOT against this issue?
> > >>> The fix should be there. Thanks!
> > >>>
> > >>> Best Regards,
> > >>> Andriy Redko
> > >>>
> > >>> On Wed, Oct 19, 2016 at 2:28 AM, Romain Manni-Bucau <
> > >>> rmannibu...@gmail.com> wrote:
> > >>>
> >  Le 19 oct. 2016 04:14, "Andriy Redko"  a écrit :
> >  >
> >  > I think this is what is happening:
> >  >  - Roman defines own CXF bus bean, named "cxf"
> > 
> >  This is a workaround to be able to lookup the bus in my workaround
> >  extension. Not doing it without my extension leads to the issue.
> > 
> >  >  - our JAX-RS CDI extension finds it and makes it a "default" bus
> to
> >  be used
> >  >for JAXRSServerFactoryBean instances
> >  >  - however, JAXRSServerFactoryBean::setApplication() would
> create a
> >  new bus
> >  >nonetheless, because the actual call to
> >  JAXRSServerFactoryBean::setBus would
> >  >be done later
> >  >
> > 
> >  This is the issue, custom bus or not.
> > 
> >  > The issue in this case is that application was created using one
> bus
> >  instance,
> >  > but JAXRSServerFactoryBean would be initialized using another bus
> >  instance. This
> >  > is my understading of the problem. Hopefully it makes sense.
> >  >
> > 
> >  The factory uses the cdi bus but the application used a "prototype"
> > bus.
> > 
> >  Side note: i deploy with tomcat embedded a single app so I am not in
> >  "multiple" deployments case.
> > 
> >  > Best Regards,
> >  > Andriy Redko
> >  >
> >  > JDA> So still something isn't clicking as I don't have Romain's
> >  issue. Is it
> >  > JDA> specific to when you have multiple deployments in your JVM?
> >  >
> >  >

Re: cxi integration: multiple buses during deployment?

[John D. Ament]

Ok this makes sense now.  I suspect this is an internal diff between owb
and weld (hence why i still want those tests).  Thanks Roma!

On Oct 19, 2016 13:16, "Romain Manni-Bucau"  wrote:

> http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk/ just run
> core
> module
>
> Think the extension was written with Weld which behaves a bit differently
> from openwebbeans on that point.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github  rmannibucau> |
> LinkedIn  | Tomitriber
>  | JavaEE Factory
> 
>
> 2016-10-19 19:08 GMT+02:00 Andrey Redko :
>
> > Hey Roman,
> >
> > Thanks a lot for verifying. Would you mind to share the sample project to
> > reproduce the issue?
> > There seems to be more things to take into account.
> > Thanks.
> >
> > Best Regards,
> > Andriy Redko
> >
> > On Wed, Oct 19, 2016 at 9:24 AM, Romain Manni-Bucau <
> rmannibu...@gmail.com
> > > wrote:
> >
> >> doesn't work but for a weirder reason.
> >>
> >> CdiBean is added programmatically - all fine
> >>
> >> Then it is directly used to get the bus (in "use the default bus" mode).
> >> This is not really fine since the CDI impl is free to wrap this so you
> >> should retrieve the actual instance of the bus and get it with this Bean
> >> instance and not supposing the CDI container will return you the
> instance
> >> you added.
> >>
> >> Concretely here are the few fixes (on 3.1.x-fixes branch):
> >> https://gist.github.com/rmannibucau/0bb8abf2e164d953be17b24b4a08e685
> >>
> >> In CDI you can't assume equals/hashcode of Bean so you need to lookup
> >> the bus instance and not use the internal one. This patch solves the
> issue.
> >>
> >>
> >>
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau  |  Blog
> >>  | Old Wordpress Blog
> >>  | Github
> >>  | LinkedIn
> >>  | Tomitriber
> >>  | JavaEE Factory
> >> 
> >>
> >> 2016-10-19 13:35 GMT+02:00 Andrey Redko :
> >>
> >>> Hi Roman,
> >>>
> >>> Thanks a lot for clarifying on things. Could you please try latest
> >>> 3.1.9-SNAPSHOT / 3.2.0-SNAPSHOT against this issue?
> >>> The fix should be there. Thanks!
> >>>
> >>> Best Regards,
> >>> Andriy Redko
> >>>
> >>> On Wed, Oct 19, 2016 at 2:28 AM, Romain Manni-Bucau <
> >>> rmannibu...@gmail.com> wrote:
> >>>
>  Le 19 oct. 2016 04:14, "Andriy Redko"  a écrit :
>  >
>  > I think this is what is happening:
>  >  - Roman defines own CXF bus bean, named "cxf"
> 
>  This is a workaround to be able to lookup the bus in my workaround
>  extension. Not doing it without my extension leads to the issue.
> 
>  >  - our JAX-RS CDI extension finds it and makes it a "default" bus to
>  be used
>  >for JAXRSServerFactoryBean instances
>  >  - however, JAXRSServerFactoryBean::setApplication() would create a
>  new bus
>  >nonetheless, because the actual call to
>  JAXRSServerFactoryBean::setBus would
>  >be done later
>  >
> 
>  This is the issue, custom bus or not.
> 
>  > The issue in this case is that application was created using one bus
>  instance,
>  > but JAXRSServerFactoryBean would be initialized using another bus
>  instance. This
>  > is my understading of the problem. Hopefully it makes sense.
>  >
> 
>  The factory uses the cdi bus but the application used a "prototype"
> bus.
> 
>  Side note: i deploy with tomcat embedded a single app so I am not in
>  "multiple" deployments case.
> 
>  > Best Regards,
>  > Andriy Redko
>  >
>  > JDA> So still something isn't clicking as I don't have Romain's
>  issue. Is it
>  > JDA> specific to when you have multiple deployments in your JVM?
>  >
>  > JDA> On Oct 18, 2016 09:02, "Romain Manni-Bucau" <
>  rmannibu...@gmail.com> wrote:
>  >
>  > >> 2016-10-18 14:43 GMT+02:00 Andrey Redko :
>  >
>  > >> > Hi Romain Manni-Bucau,
>  > >> >
>  > >> > Yes, technically we do have this option, but I would suggest to
>  use
>  > >> > explicit wirings instead of thread local context.  It
>  > >> > could have quite a number of side effects. I hope you would
>  agree with
>  > >> > that.
>  > >> >
>  > >> >
>  > >> I agree it is better but side effect should be null since the
>  value is
>  > >> cleaned up after. If not then runtime can have side effects which
>  would be
>  > >> a bigger issue ;)
>  >
>  >
>  > >> > Thanks!
>  > >> >
> 

Re: cxi integration: multiple buses during deployment?

[Romain Manni-Bucau]

http://svn.apache.org/repos/asf/openwebbeans/microwave/trunk/ just run core
module

Think the extension was written with Weld which behaves a bit differently
from openwebbeans on that point.


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-10-19 19:08 GMT+02:00 Andrey Redko :

> Hey Roman,
>
> Thanks a lot for verifying. Would you mind to share the sample project to
> reproduce the issue?
> There seems to be more things to take into account.
> Thanks.
>
> Best Regards,
> Andriy Redko
>
> On Wed, Oct 19, 2016 at 9:24 AM, Romain Manni-Bucau  > wrote:
>
>> doesn't work but for a weirder reason.
>>
>> CdiBean is added programmatically - all fine
>>
>> Then it is directly used to get the bus (in "use the default bus" mode).
>> This is not really fine since the CDI impl is free to wrap this so you
>> should retrieve the actual instance of the bus and get it with this Bean
>> instance and not supposing the CDI container will return you the instance
>> you added.
>>
>> Concretely here are the few fixes (on 3.1.x-fixes branch):
>> https://gist.github.com/rmannibucau/0bb8abf2e164d953be17b24b4a08e685
>>
>> In CDI you can't assume equals/hashcode of Bean so you need to lookup
>> the bus instance and not use the internal one. This patch solves the issue.
>>
>>
>>
>>
>>
>> Romain Manni-Bucau
>> @rmannibucau  |  Blog
>>  | Old Wordpress Blog
>>  | Github
>>  | LinkedIn
>>  | Tomitriber
>>  | JavaEE Factory
>> 
>>
>> 2016-10-19 13:35 GMT+02:00 Andrey Redko :
>>
>>> Hi Roman,
>>>
>>> Thanks a lot for clarifying on things. Could you please try latest
>>> 3.1.9-SNAPSHOT / 3.2.0-SNAPSHOT against this issue?
>>> The fix should be there. Thanks!
>>>
>>> Best Regards,
>>> Andriy Redko
>>>
>>> On Wed, Oct 19, 2016 at 2:28 AM, Romain Manni-Bucau <
>>> rmannibu...@gmail.com> wrote:
>>>
 Le 19 oct. 2016 04:14, "Andriy Redko"  a écrit :
 >
 > I think this is what is happening:
 >  - Roman defines own CXF bus bean, named "cxf"

 This is a workaround to be able to lookup the bus in my workaround
 extension. Not doing it without my extension leads to the issue.

 >  - our JAX-RS CDI extension finds it and makes it a "default" bus to
 be used
 >for JAXRSServerFactoryBean instances
 >  - however, JAXRSServerFactoryBean::setApplication() would create a
 new bus
 >nonetheless, because the actual call to
 JAXRSServerFactoryBean::setBus would
 >be done later
 >

 This is the issue, custom bus or not.

 > The issue in this case is that application was created using one bus
 instance,
 > but JAXRSServerFactoryBean would be initialized using another bus
 instance. This
 > is my understading of the problem. Hopefully it makes sense.
 >

 The factory uses the cdi bus but the application used a "prototype" bus.

 Side note: i deploy with tomcat embedded a single app so I am not in
 "multiple" deployments case.

 > Best Regards,
 > Andriy Redko
 >
 > JDA> So still something isn't clicking as I don't have Romain's
 issue. Is it
 > JDA> specific to when you have multiple deployments in your JVM?
 >
 > JDA> On Oct 18, 2016 09:02, "Romain Manni-Bucau" <
 rmannibu...@gmail.com> wrote:
 >
 > >> 2016-10-18 14:43 GMT+02:00 Andrey Redko :
 >
 > >> > Hi Romain Manni-Bucau,
 > >> >
 > >> > Yes, technically we do have this option, but I would suggest to
 use
 > >> > explicit wirings instead of thread local context.  It
 > >> > could have quite a number of side effects. I hope you would
 agree with
 > >> > that.
 > >> >
 > >> >
 > >> I agree it is better but side effect should be null since the
 value is
 > >> cleaned up after. If not then runtime can have side effects which
 would be
 > >> a bigger issue ;)
 >
 >
 > >> > Thanks!
 > >> >
 > >> > Best Regards,
 > >> > Andriy Redko
 > >> >
 > >> >
 > >> > On Tue, Oct 18, 2016 at 7:49 AM, Romain Manni-Bucau <
 > >> rmannibu...@gmail.com
 > >> > >
 > >> > wrote:
 > >> >
 > >> > > We also have option 3: set the thread bus as in the workaround
 I used.
 > >> > >
 > >> > >
 > >> > > Romain Manni-Bucau
 > >> > > @rmannibucau  |  Blog
 > >> > >  

Re: cxi integration: multiple buses during deployment?

[Andrey Redko]

Hey Roman,

Thanks a lot for verifying. Would you mind to share the sample project to
reproduce the issue?
There seems to be more things to take into account.
Thanks.

Best Regards,
Andriy Redko

On Wed, Oct 19, 2016 at 9:24 AM, Romain Manni-Bucau 
wrote:

> doesn't work but for a weirder reason.
>
> CdiBean is added programmatically - all fine
>
> Then it is directly used to get the bus (in "use the default bus" mode).
> This is not really fine since the CDI impl is free to wrap this so you
> should retrieve the actual instance of the bus and get it with this Bean
> instance and not supposing the CDI container will return you the instance
> you added.
>
> Concretely here are the few fixes (on 3.1.x-fixes branch):
> https://gist.github.com/rmannibucau/0bb8abf2e164d953be17b24b4a08e685
>
> In CDI you can't assume equals/hashcode of Bean so you need to lookup
> the bus instance and not use the internal one. This patch solves the issue.
>
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Wordpress Blog
>  | Github
>  | LinkedIn
>  | Tomitriber
>  | JavaEE Factory
> 
>
> 2016-10-19 13:35 GMT+02:00 Andrey Redko :
>
>> Hi Roman,
>>
>> Thanks a lot for clarifying on things. Could you please try latest
>> 3.1.9-SNAPSHOT / 3.2.0-SNAPSHOT against this issue?
>> The fix should be there. Thanks!
>>
>> Best Regards,
>> Andriy Redko
>>
>> On Wed, Oct 19, 2016 at 2:28 AM, Romain Manni-Bucau <
>> rmannibu...@gmail.com> wrote:
>>
>>> Le 19 oct. 2016 04:14, "Andriy Redko"  a écrit :
>>> >
>>> > I think this is what is happening:
>>> >  - Roman defines own CXF bus bean, named "cxf"
>>>
>>> This is a workaround to be able to lookup the bus in my workaround
>>> extension. Not doing it without my extension leads to the issue.
>>>
>>> >  - our JAX-RS CDI extension finds it and makes it a "default" bus to
>>> be used
>>> >for JAXRSServerFactoryBean instances
>>> >  - however, JAXRSServerFactoryBean::setApplication() would create a
>>> new bus
>>> >nonetheless, because the actual call to
>>> JAXRSServerFactoryBean::setBus would
>>> >be done later
>>> >
>>>
>>> This is the issue, custom bus or not.
>>>
>>> > The issue in this case is that application was created using one bus
>>> instance,
>>> > but JAXRSServerFactoryBean would be initialized using another bus
>>> instance. This
>>> > is my understading of the problem. Hopefully it makes sense.
>>> >
>>>
>>> The factory uses the cdi bus but the application used a "prototype" bus.
>>>
>>> Side note: i deploy with tomcat embedded a single app so I am not in
>>> "multiple" deployments case.
>>>
>>> > Best Regards,
>>> > Andriy Redko
>>> >
>>> > JDA> So still something isn't clicking as I don't have Romain's issue.
>>> Is it
>>> > JDA> specific to when you have multiple deployments in your JVM?
>>> >
>>> > JDA> On Oct 18, 2016 09:02, "Romain Manni-Bucau" <
>>> rmannibu...@gmail.com> wrote:
>>> >
>>> > >> 2016-10-18 14:43 GMT+02:00 Andrey Redko :
>>> >
>>> > >> > Hi Romain Manni-Bucau,
>>> > >> >
>>> > >> > Yes, technically we do have this option, but I would suggest to
>>> use
>>> > >> > explicit wirings instead of thread local context.  It
>>> > >> > could have quite a number of side effects. I hope you would agree
>>> with
>>> > >> > that.
>>> > >> >
>>> > >> >
>>> > >> I agree it is better but side effect should be null since the value
>>> is
>>> > >> cleaned up after. If not then runtime can have side effects which
>>> would be
>>> > >> a bigger issue ;)
>>> >
>>> >
>>> > >> > Thanks!
>>> > >> >
>>> > >> > Best Regards,
>>> > >> > Andriy Redko
>>> > >> >
>>> > >> >
>>> > >> > On Tue, Oct 18, 2016 at 7:49 AM, Romain Manni-Bucau <
>>> > >> rmannibu...@gmail.com
>>> > >> > >
>>> > >> > wrote:
>>> > >> >
>>> > >> > > We also have option 3: set the thread bus as in the workaround
>>> I used.
>>> > >> > >
>>> > >> > >
>>> > >> > > Romain Manni-Bucau
>>> > >> > > @rmannibucau  |  Blog
>>> > >> > >  | Old Wordpress Blog
>>> > >> > >  | Github <
>>> https://github.com/
>>> > >> > > rmannibucau> |
>>> > >> > > LinkedIn  | Tomitriber
>>> > >> > >  | JavaEE Factory
>>> > >> > > 
>>> > >> > >
>>> > >> > > 2016-10-18 13:47 GMT+02:00 Sergey Beryozkin <
>>> sberyoz...@gmail.com>:
>>> > >> > >
>>> > >> > > > Hi Andriy
>>> > >> > > > yes, option 1 is probably the simplest for the CDI
>>> integration path,
>>> > >> > > >
>>> > >> > > > Thanks, Sergey
>>> > >> > > >
>>> > >> > > > On 18/10/16 12:43, Andrey Redko wrote:
>>> > >> > > >
>>> > >> > > >> Hey guys,
>>> > >> > > >>
>>> > >> > > >> Indeed, the

Re: ActAs implementation from the STS

[Colm O hEigeartaigh]

Fixed here for the record: https://issues.apache.org/jira/browse/CXF-7099

Colm.

On Tue, Oct 18, 2016 at 8:50 AM, Jan Bernhardt 
wrote:

> Hi CXF developers,
>
> I was looking at the Test Cases for the STS ActAs support
> (org.apache.cxf.sts.token.provider.SAMLProviderActAsTest).
> However, they confused me a bit, because in all cases the NameIdentifier
> ends up being the same as the ActAs attribute Statement.
> If both have the same value, what would be the added value to the
> attribute Statement?
> If I understand the specification correctly ActAs should provide both
> information, the principal to "act as" as well as the principle acting as
> the other user.
>
> So does that mean our Test-Cases do not cover this aspect or is our
> implementation wrong?
> What should be the expected outcome?
>
> Best regards
> Jan
>
> > -Ursprüngliche Nachricht-
> > Von: Jan Bernhardt [mailto:jbernha...@talend.com]
> > Gesendet: Mittwoch, 12. Oktober 2016 15:12
> > An: us...@cxf.apache.org
> > Betreff: ActAs implementation from the STS
> >
> > Hi CXF Users,
> >
> > I'm currently trying to figure out the differences between onBehalfOf and
> > ActAs token delegation.
> > And whether the implementation at the STS is correct or not.
> >
> > I could not find anything substantial in the WS-Trust specification.
> > Is our implementation within the STS just a guessing because of missing
> > specification, or is there some specification I'm not aware of?
> >
> > Kind regards
> > Jan
> >
> > --
> > Jan Bernhardt
> >
> > Talend Community Coder
> > http://coders.talend.com
> >
> > Visit my Blog
> > https://janbernhardt.blogspot.de
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Re: cxi integration: multiple buses during deployment?

[Romain Manni-Bucau]

doesn't work but for a weirder reason.

CdiBean is added programmatically - all fine

Then it is directly used to get the bus (in "use the default bus" mode).
This is not really fine since the CDI impl is free to wrap this so you
should retrieve the actual instance of the bus and get it with this Bean
instance and not supposing the CDI container will return you the instance
you added.

Concretely here are the few fixes (on 3.1.x-fixes branch):
https://gist.github.com/rmannibucau/0bb8abf2e164d953be17b24b4a08e685

In CDI you can't assume equals/hashcode of Bean so you need to lookup
the bus instance and not use the internal one. This patch solves the issue.





Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


2016-10-19 13:35 GMT+02:00 Andrey Redko :

> Hi Roman,
>
> Thanks a lot for clarifying on things. Could you please try latest
> 3.1.9-SNAPSHOT / 3.2.0-SNAPSHOT against this issue?
> The fix should be there. Thanks!
>
> Best Regards,
> Andriy Redko
>
> On Wed, Oct 19, 2016 at 2:28 AM, Romain Manni-Bucau  > wrote:
>
>> Le 19 oct. 2016 04:14, "Andriy Redko"  a écrit :
>> >
>> > I think this is what is happening:
>> >  - Roman defines own CXF bus bean, named "cxf"
>>
>> This is a workaround to be able to lookup the bus in my workaround
>> extension. Not doing it without my extension leads to the issue.
>>
>> >  - our JAX-RS CDI extension finds it and makes it a "default" bus to be
>> used
>> >for JAXRSServerFactoryBean instances
>> >  - however, JAXRSServerFactoryBean::setApplication() would create a
>> new bus
>> >nonetheless, because the actual call to
>> JAXRSServerFactoryBean::setBus would
>> >be done later
>> >
>>
>> This is the issue, custom bus or not.
>>
>> > The issue in this case is that application was created using one bus
>> instance,
>> > but JAXRSServerFactoryBean would be initialized using another bus
>> instance. This
>> > is my understading of the problem. Hopefully it makes sense.
>> >
>>
>> The factory uses the cdi bus but the application used a "prototype" bus.
>>
>> Side note: i deploy with tomcat embedded a single app so I am not in
>> "multiple" deployments case.
>>
>> > Best Regards,
>> > Andriy Redko
>> >
>> > JDA> So still something isn't clicking as I don't have Romain's issue.
>> Is it
>> > JDA> specific to when you have multiple deployments in your JVM?
>> >
>> > JDA> On Oct 18, 2016 09:02, "Romain Manni-Bucau" 
>> wrote:
>> >
>> > >> 2016-10-18 14:43 GMT+02:00 Andrey Redko :
>> >
>> > >> > Hi Romain Manni-Bucau,
>> > >> >
>> > >> > Yes, technically we do have this option, but I would suggest to use
>> > >> > explicit wirings instead of thread local context.  It
>> > >> > could have quite a number of side effects. I hope you would agree
>> with
>> > >> > that.
>> > >> >
>> > >> >
>> > >> I agree it is better but side effect should be null since the value
>> is
>> > >> cleaned up after. If not then runtime can have side effects which
>> would be
>> > >> a bigger issue ;)
>> >
>> >
>> > >> > Thanks!
>> > >> >
>> > >> > Best Regards,
>> > >> > Andriy Redko
>> > >> >
>> > >> >
>> > >> > On Tue, Oct 18, 2016 at 7:49 AM, Romain Manni-Bucau <
>> > >> rmannibu...@gmail.com
>> > >> > >
>> > >> > wrote:
>> > >> >
>> > >> > > We also have option 3: set the thread bus as in the workaround I
>> used.
>> > >> > >
>> > >> > >
>> > >> > > Romain Manni-Bucau
>> > >> > > @rmannibucau  |  Blog
>> > >> > >  | Old Wordpress Blog
>> > >> > >  | Github > > >> > > rmannibucau> |
>> > >> > > LinkedIn  | Tomitriber
>> > >> > >  | JavaEE Factory
>> > >> > > 
>> > >> > >
>> > >> > > 2016-10-18 13:47 GMT+02:00 Sergey Beryozkin <
>> sberyoz...@gmail.com>:
>> > >> > >
>> > >> > > > Hi Andriy
>> > >> > > > yes, option 1 is probably the simplest for the CDI integration
>> path,
>> > >> > > >
>> > >> > > > Thanks, Sergey
>> > >> > > >
>> > >> > > > On 18/10/16 12:43, Andrey Redko wrote:
>> > >> > > >
>> > >> > > >> Hey guys,
>> > >> > > >>
>> > >> > > >> Indeed, there is an issue with CDI and usage of custom bus. I
>> think
>> > >> > > there
>> > >> > > >> are couple of the options
>> > >> > > >> we have here:
>> > >> > > >>  - pass the bus instance to ResourceUtils::createApplication,
>> in
>> > >> this
>> > >> > > >> case
>> > >> > > >> if bus is not set, the behaviour would be exactly the same
>> > >> > > >>  - change the way JAXRSServerFactoryBean is being created so
>> we
>> > >> could
>> > >> > > set
>> > >> > > >> the bus before

Re: cxi integration: multiple buses during deployment?

[Andrey Redko]

Hi Roman,

Thanks a lot for clarifying on things. Could you please try latest
3.1.9-SNAPSHOT / 3.2.0-SNAPSHOT against this issue?
The fix should be there. Thanks!

Best Regards,
Andriy Redko

On Wed, Oct 19, 2016 at 2:28 AM, Romain Manni-Bucau 
wrote:

> Le 19 oct. 2016 04:14, "Andriy Redko"  a écrit :
> >
> > I think this is what is happening:
> >  - Roman defines own CXF bus bean, named "cxf"
>
> This is a workaround to be able to lookup the bus in my workaround
> extension. Not doing it without my extension leads to the issue.
>
> >  - our JAX-RS CDI extension finds it and makes it a "default" bus to be
> used
> >for JAXRSServerFactoryBean instances
> >  - however, JAXRSServerFactoryBean::setApplication() would create a new
> bus
> >nonetheless, because the actual call to
> JAXRSServerFactoryBean::setBus would
> >be done later
> >
>
> This is the issue, custom bus or not.
>
> > The issue in this case is that application was created using one bus
> instance,
> > but JAXRSServerFactoryBean would be initialized using another bus
> instance. This
> > is my understading of the problem. Hopefully it makes sense.
> >
>
> The factory uses the cdi bus but the application used a "prototype" bus.
>
> Side note: i deploy with tomcat embedded a single app so I am not in
> "multiple" deployments case.
>
> > Best Regards,
> > Andriy Redko
> >
> > JDA> So still something isn't clicking as I don't have Romain's issue.
> Is it
> > JDA> specific to when you have multiple deployments in your JVM?
> >
> > JDA> On Oct 18, 2016 09:02, "Romain Manni-Bucau" 
> wrote:
> >
> > >> 2016-10-18 14:43 GMT+02:00 Andrey Redko :
> >
> > >> > Hi Romain Manni-Bucau,
> > >> >
> > >> > Yes, technically we do have this option, but I would suggest to use
> > >> > explicit wirings instead of thread local context.  It
> > >> > could have quite a number of side effects. I hope you would agree
> with
> > >> > that.
> > >> >
> > >> >
> > >> I agree it is better but side effect should be null since the value is
> > >> cleaned up after. If not then runtime can have side effects which
> would be
> > >> a bigger issue ;)
> >
> >
> > >> > Thanks!
> > >> >
> > >> > Best Regards,
> > >> > Andriy Redko
> > >> >
> > >> >
> > >> > On Tue, Oct 18, 2016 at 7:49 AM, Romain Manni-Bucau <
> > >> rmannibu...@gmail.com
> > >> > >
> > >> > wrote:
> > >> >
> > >> > > We also have option 3: set the thread bus as in the workaround I
> used.
> > >> > >
> > >> > >
> > >> > > Romain Manni-Bucau
> > >> > > @rmannibucau  |  Blog
> > >> > >  | Old Wordpress Blog
> > >> > >  | Github  > >> > > rmannibucau> |
> > >> > > LinkedIn  | Tomitriber
> > >> > >  | JavaEE Factory
> > >> > > 
> > >> > >
> > >> > > 2016-10-18 13:47 GMT+02:00 Sergey Beryozkin  >:
> > >> > >
> > >> > > > Hi Andriy
> > >> > > > yes, option 1 is probably the simplest for the CDI integration
> path,
> > >> > > >
> > >> > > > Thanks, Sergey
> > >> > > >
> > >> > > > On 18/10/16 12:43, Andrey Redko wrote:
> > >> > > >
> > >> > > >> Hey guys,
> > >> > > >>
> > >> > > >> Indeed, there is an issue with CDI and usage of custom bus. I
> think
> > >> > > there
> > >> > > >> are couple of the options
> > >> > > >> we have here:
> > >> > > >>  - pass the bus instance to ResourceUtils::createApplication,
> in
> > >> this
> > >> > > >> case
> > >> > > >> if bus is not set, the behaviour would be exactly the same
> > >> > > >>  - change the way JAXRSServerFactoryBean is being created so we
> > >> could
> > >> > > set
> > >> > > >> the bus before setting the application
> > >> > > >>
> > >> > > >> Romain Manni-Bucau, do we have a ticket for it? If not, could
> you
> > >> > please
> > >> > > >> create one, we'll work on a fix for it.
> > >> > > >> Thanks.
> > >> > > >>
> > >> > > >>
> > >> > > >> On Tue, Oct 18, 2016 at 7:08 AM, Romain Manni-Bucau <
> > >> > > >> rmannibu...@gmail.com>
> > >> > > >> wrote:
> > >> > > >>
> > >> > > >> Not yet something failling i can share but globally I ended up
> doing
> > >> > > that:
> > >> > > >>>
> > >> > > >>> @Named("cxf")
> > >> > > >>> @ApplicationScoped
> > >> > > >>> public class BusInstance implements Bus {
> > >> > > >>> @Delegate
> > >> > > >>> private Bus delegate = new ExtensionManagerBus();
> > >> > > >>> }
> > >> > > >>> public class OWBAutoSetup implements
> ServletContainerInitializer {
> > >> > > >>> @Override
> > >> > > >>> public void onStartup(final Set> c, final
> ServletContext
> > >> > ctx)
> > >> > > >>> throws ServletException {
> > >> > > >>>
> > >> > > >>> ctx.addListener(WebBeansConfigurationListener.class);
> > >> > > >>> ctx.addListener(WebBeansConfigurationHttpSessi
> onListener.class);
> > >> > > >>> }
> > >> > > >>> }
> > >> > > >>>
> > >> > > >>>
> > >> > > >>>
> > >> > > >>> public class CxfC

[GitHub] cxf pull request #:

[sberyozkin]

Github user sberyozkin commented on the pull request:


https://github.com/apache/cxf/commit/66f652cca276fba8395496454e870cfb82439549#commitcomment-19482592
  
Hi, thanks, has just been fixed. Please use getParameterNames or Map for now


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cxf pull request #:

[willuhn]

Github user willuhn commented on the pull request:


https://github.com/apache/cxf/commit/66f652cca276fba8395496454e870cfb82439549#commitcomment-19482455
  
HttpServletRequestFilter#getParameterValues(String name) now creates a 
NullPointerException in line 75:


https://github.com/apache/cxf/blob/master/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/impl/HttpServletRequestFilter.java#L75

Problematic code:
`readFromParamsIfNeeded();`
`value = formParams.get(name).toArray(new String[]{});`

If "formParams" does not contain a key with the requested parameter name, 
the "get" returns NULL. The "toArray" after that now throws a 
NullPointerException




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---