[jira] [Comment Edited] (CXF-4199) Support class-scanning for discovering JAX-RS providers

["Sergey Beryozkin (JIRA)" <ji...@apache.org>]

    [ 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:02 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 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





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 help 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)