[
https://issues.apache.org/jira/browse/CXF-4199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13844206#comment-13844206
]
Sergey Beryozkin commented on CXF-4199:
---------------------------------------
Hi Andriy, yes, it is very close, thanks. we need to encapsulate it a bit to
make sure it works without Spring, similar to this approach,
http://svn.apache.org/repos/asf/cxf/trunk/core/src/main/java/org/apache/cxf/common/util/ClassHelper.java
example, so that a call to ClassScanner works from Blueprint or any CXF code
which needs the resources scanning support, the no-op handler will be used for
now in non-Spring cases; we can of course start from putting it directly into
core/spring, but the minor encapsulation should do it. I can work with the
patch and do few minor updates on it.
Hmm... Just spotted it, with this patch (or more precisely, this my idea) we
lose the ability to load classes with ApplicationContext. You were right, we
have to keep the actual instantiation out of the scanner, if we want to make it
reusable across. Let me play a bit wit it
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, patch-classpath-scaner.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.4#6159)
