You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by "John D. Ament" <jo...@apache.org> on 2017/11/27 14:22:06 UTC
Rethinking how JAX-RS customizations are looked up in CDI
I was wondering, does it really make sense
for JAXRSServerFactoryCustomizationExtension implementations to be CDI
beans? It may sound odd, but typically in CDI that kind of feature is done
as a service loader pattern. These are classes that should only be used
once, so keeping them in memory is a bit of a waste. I think recently we
saw some issues with SSE integration, where we had to make the archive a
full bean archive (bean-discovery-mode=all) just to ensure that this bean
was looked up. It may make more sense if these are ServiceLoader based
classes, this way we just have to register it in META-INF/services without
adding any CDI specific features to the JAR.
At the same time, I also wonder if this causes an issue for Java 9
modules. Does the dependency have to always be there, or can it be an
optional dependency (my module foo is weak, so I have no idea if that's
even feasible).
John
Re: Rethinking how JAX-RS customizations are looked up in CDI
Posted by Andriy Redko <dr...@gmail.com>.
Hey John,
You have a good point, there is nothing CDI specific about factory bean customization we have right now,
the only CDI specific thing is that we had a problem with CDI flow and number of ways to solve it. If
we move such customizations to service loader, we could also move the implementation itself from CDI
extension to JAXRSServerFactoryBean, so the servlet-based configuration (the transport) becomes
optional/not necessary. It's worth trying out I think.
Thanks.
Best Regards,
Andriy Redko
JDA> Andriy,
JDA> Well, I think the difference here is that server customizations are not CDI specific. It looks like they were put
JDA> there, but I can think of other use cases where an externally managed JAXRSServerFactoryBean is externally managed,
JDA> and being able to invoke a series of callbacks to further tweak that server would be very useful.
JDA> It's just a thought, since I was playing around with how to automate SSE integration when someone else creates the
JDA> factory, without using CDI; e.g. other cases of CXFNonSpringJaxrsServlet.
JDA> John
JDA> On 2017-11-27 21:40, Andriy Redko <dr...@gmail.com> wrote:
>> Hey John,
>>
>> I think this would be a better alternative, we could use the same mechanism
>> as for external providers (using ServiceLoader, as also you suggested). I am
>> not sure what is the best option, it looks somewhat nature to use CDI capabilities
>> to fullfil CDI-specific cases, but practically speaking, ServiceLoader would be
>> enough in this case.
>>
>> Thanks.
>>
>> Best Regards,
>> Andriy Redko
>>
>> JDA> I was wondering, does it really make sense
>> JDA> for JAXRSServerFactoryCustomizationExtension implementations to be CDI
>> JDA> beans? It may sound odd, but typically in CDI that kind of feature is done
>> JDA> as a service loader pattern. These are classes that should only be used
>> JDA> once, so keeping them in memory is a bit of a waste. I think recently we
>> JDA> saw some issues with SSE integration, where we had to make the archive a
>> JDA> full bean archive (bean-discovery-mode=all) just to ensure that this bean
>> JDA> was looked up. It may make more sense if these are ServiceLoader based
>> JDA> classes, this way we just have to register it in META-INF/services without
>> JDA> adding any CDI specific features to the JAR.
>>
>> JDA> At the same time, I also wonder if this causes an issue for Java 9
>> JDA> modules. Does the dependency have to always be there, or can it be an
>> JDA> optional dependency (my module foo is weak, so I have no idea if that's
>> JDA> even feasible).
>>
>> JDA> John
>>
>>
Re: Rethinking how JAX-RS customizations are looked up in CDI
Posted by "John D. Ament" <jo...@apache.org>.
Andriy,
Well, I think the difference here is that server customizations are not CDI specific. It looks like they were put there, but I can think of other use cases where an externally managed JAXRSServerFactoryBean is externally managed, and being able to invoke a series of callbacks to further tweak that server would be very useful.
It's just a thought, since I was playing around with how to automate SSE integration when someone else creates the factory, without using CDI; e.g. other cases of CXFNonSpringJaxrsServlet.
John
On 2017-11-27 21:40, Andriy Redko <dr...@gmail.com> wrote:
> Hey John,
>
> I think this would be a better alternative, we could use the same mechanism
> as for external providers (using ServiceLoader, as also you suggested). I am
> not sure what is the best option, it looks somewhat nature to use CDI capabilities
> to fullfil CDI-specific cases, but practically speaking, ServiceLoader would be
> enough in this case.
>
> Thanks.
>
> Best Regards,
> Andriy Redko
>
> JDA> I was wondering, does it really make sense
> JDA> for JAXRSServerFactoryCustomizationExtension implementations to be CDI
> JDA> beans? It may sound odd, but typically in CDI that kind of feature is done
> JDA> as a service loader pattern. These are classes that should only be used
> JDA> once, so keeping them in memory is a bit of a waste. I think recently we
> JDA> saw some issues with SSE integration, where we had to make the archive a
> JDA> full bean archive (bean-discovery-mode=all) just to ensure that this bean
> JDA> was looked up. It may make more sense if these are ServiceLoader based
> JDA> classes, this way we just have to register it in META-INF/services without
> JDA> adding any CDI specific features to the JAR.
>
> JDA> At the same time, I also wonder if this causes an issue for Java 9
> JDA> modules. Does the dependency have to always be there, or can it be an
> JDA> optional dependency (my module foo is weak, so I have no idea if that's
> JDA> even feasible).
>
> JDA> John
>
>
Re: Rethinking how JAX-RS customizations are looked up in CDI
Posted by Andriy Redko <dr...@gmail.com>.
Hey John,
I think this would be a better alternative, we could use the same mechanism
as for external providers (using ServiceLoader, as also you suggested). I am
not sure what is the best option, it looks somewhat nature to use CDI capabilities
to fullfil CDI-specific cases, but practically speaking, ServiceLoader would be
enough in this case.
Thanks.
Best Regards,
Andriy Redko
JDA> I was wondering, does it really make sense
JDA> for JAXRSServerFactoryCustomizationExtension implementations to be CDI
JDA> beans? It may sound odd, but typically in CDI that kind of feature is done
JDA> as a service loader pattern. These are classes that should only be used
JDA> once, so keeping them in memory is a bit of a waste. I think recently we
JDA> saw some issues with SSE integration, where we had to make the archive a
JDA> full bean archive (bean-discovery-mode=all) just to ensure that this bean
JDA> was looked up. It may make more sense if these are ServiceLoader based
JDA> classes, this way we just have to register it in META-INF/services without
JDA> adding any CDI specific features to the JAR.
JDA> At the same time, I also wonder if this causes an issue for Java 9
JDA> modules. Does the dependency have to always be there, or can it be an
JDA> optional dependency (my module foo is weak, so I have no idea if that's
JDA> even feasible).
JDA> John