[
https://issues.apache.org/jira/browse/CXF-4199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13841282#comment-13841282
]
Sergey Beryozkin edited comment on CXF-4199 at 12/6/13 2:03 PM:
----------------------------------------------------------------
Hi Andriy
I've created https://issues.apache.org/jira/browse/CXF-5439 to get all the main
native CXF providers marked too. I'm not sure yet how fast we should go there,
perhaps we should wait till https://issues.apache.org/jira/browse/CXF-5441 gets
resolved, perhaps the auto-discovery of CXF native providers should work
consistently for all the frontends.
I think what we should do in meantime is to encapsulate the auto-discovery code
into a helper class. For example, we have org.apache.common.util.ProxyHelper
which tries Spring first and then defaults to the basic level support.
So what about this plan:
1. org.apache.common.util.ClassPathScanner, it will try Spring, default to
no-op, it will have several helper methods, example, it will scan for .class by
default by can accept other extensions like .xsd. It will also optionally
create class instances or return classes only. It will optionally accept a list
of required annotations and return a Map<Annotation, List<Object>> with every
annotation linked to a corresponding List of objects
2. Update JAXRS Server Spring factory to use ClassPathScanner
3. Update JAXRS Client Spring factory to use ClassPathScanner, except that it
will create providers only, and return a service class
This will probably let us completely resolve this issue.
When we have a ClassPathScanner then JAXWS Serrver Spring factory might also
use it and then we can also utilize it for discovering the rest of CXF
providers.
And then
4. We will review how to provide a light-weight discovery support for non
Spring apps, encapsulated within that Scanner.
For example, I've just found
http://sourceforge.net/projects/extcos/files/releases/0.4b/
which seems to be pretty light weight and it depends on ASM and CXF has an
optional ASM dependency too.
Thoughts ?
Thanks, Sergey
was (Author: sergey_beryozkin):
Hi Andriy
I've created https://issues.apache.org/jira/browse/CXF-5439 to get all the main
native CXF providers marked too. I'm not sure yet how fast we should go there,
perhaps we should wait till https://issues.apache.org/jira/browse/CXF-5441 gets
resolved, perhaps the auto-discovery of CXF native providers should work
consistently for all the frontends.
I think what we should do in meantime is to encapsulate the auto-discovery code
into a helper class. For example, we have org.apache.common.util.ProxyHelper
which tries Spring first and then defaults to the basic level support.
So what about this plan:
1. org.apache.common.util.ClassPathScanner, it will try Spring, default to
no-op, it will have several helper methods, example, it will scan for .class by
default by can accept other extensions like .xsd. It will also optionally
create class instances or return classes only. It will optionally accept a list
of required annotations and return a Map<Annotation, List<Object>> with every
annotation linked to a corresponding List of objects
2. Update JAXRS Server Spring factory to use ClassPathScanner
3. Update JAXRS Client Spring factory to use ClassPathScanner, except that it
will create providers only, and return a service class
This will probably let us completely resolve this issue.
When we have a ClassPathScanner then JAXWS Serrver Spring factory might also
use it and then we can also utilize it for discovering the rest of CXF
providers.
And then
4. We will review how to provide a light-weight discovery support for non
Spring apps, encapsulated withing that Scanner.
For example, I've just found
http://sourceforge.net/projects/extcos/files/releases/0.4b/
which seems to be pretty light weight and it depends on ASM and CXF has an
optional ASM dependency too.
Thoughts ?
Thanks, Sergey
> Support class-scanning for discovering JAX-RS providers
> --------------------------------------------------------
>
> Key: CXF-4199
> URL: https://issues.apache.org/jira/browse/CXF-4199
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Reporter: Sergey Beryozkin
> Attachments: patch-base-packages-discovery-all-packages.txt,
> patch-base-packages-discovery.txt
>
>
> With the search extensions module containing a provider the time has come to
> support the optional class-scanning. Will help in cases when the providers
> are simple and no extra configuration is expected. Post 2.6 though
--
This message was sent by Atlassian JIRA
(v6.1#6144)
