On 28/11/13 10:32, António Mota wrote:
It's about the trailing slash really:
Jersey
requestContext.getUriInfo().getBaseUri().toString() -> "
http://app.antoniom:8080/core31/rest/";
CXF
requestContext.getUriInfo().getBaseUri().toString() -> "
http://app.antoniom:8080/core31/rest";
Thanks, are you sure it is not the other way around ?
I see CXF ServletController adding a trailing "/" to the correctly
calculated base URL which is not exactly right.
If it is indeed the case in your scenario, then I'd say Jersey might be
not correct, where does it take "/" from ?
It might make sense to open a JAX-RS spec JIRA to ensure
UriInfo.getBaseUri() produces consistent values. Though it can be hard
to make it consistent across multiple containers.
For example, Jetty HttpServletRequest.getServletPath() returns "/test"
for a url pattern "/test/*". You may get the other implementation
returning "/test/"...
Sergey
Cheers.
* Melhores cumprimentos / Beir beannacht / Best regards *
*______________________________________________________*
*António Manuel dos Santos Mota <http://gplus.to/amsmota>*
*http://www.linkedin.com/in/amsmota* <http://www.linkedin.com/in/amsmota>
*______________________________________________________*
On 27 November 2013 16:05, Sergey Beryozkin <[email protected]> wrote:
On 27/11/13 15:59, António Mota wrote:
That's a detail, I don't know if there is a specification for that, but
requestContext.getUriInfo().getBaseUri().toString();
requestContext.getUriInfo().getAbsolutePath().toString();
return slightly different values in CXF and jersey. It has to do with
initial / if you want tomorrow I can send you exactly what's different.
That would be helpful, please do.
It must've been all tested in TCK, UriInfo methods specifically, but I'd
like to check it,
Sergey
Cheers.
On 27 November 2013 15:43, Sergey Beryozkin <[email protected]> wrote:
By the way, you mentioned something about modifying
ContainerRequestContext, something to do with URIs, is it a CXF issue ?
Sergey
On 27/11/13 15:41, Sergey Beryozkin wrote:
On 27/11/13 15:28, António Mota wrote:
I think I'm lost now... Please note my comments inline.
On 26 November 2013 17:29, Sergey Beryozkin <[email protected]>
wrote:
Well, typically users would not use Application while also working
with
Spring, they would just register roots/providers with jaxrs:server.
My Application defines the classes (or instances) that provide the
services
itself, and those services are (can be) quite complex and have lots of
injected beans (be it injected with Spring or another DI container).
If I
let the instantiation of my service classes to the Application itself
(and
the JAX-RS implementation behind it) how can I assure those dependency
injections?
I don't know, may be you can your Application explicitly loading an
application context and extracting the service beans from it; or avoid
using Application and use CXF jaxrs:server endpoint in a Spring context
CXFNonSpringJaxrsServlet will work with Application, and will
initialize
the server as needed.
I did try CXFNonSpringJaxrsServlet, and in all the cases I mentioned
before
I always got the same error:
javax.servlet.ServletException: At least one resource class should
be
specified
at
org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.
getServiceClasses(
CXFNonSpringJaxrsServlet.java:266)
at
org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet.init(
CXFNonSpringJaxrsServlet.java:118)
You have to specify your Application as a servlet parameter, per the
spec
Application is supposed to be a completely portable 'container',
JAX-RS
supports the injection of JAX-RS contexts into Application, but if
you'd
like to mix it up with Spring/etc, then I guess it is becoming the
implementation/framework specific.
It still be portable since I'm using the javax.inject.Inject
annotation and
not the Spring-dependent autowired annotation. But otherwise how do you
take care of DI?
May be we can support the auto-discovery of Applications from Spring
application contexts, we are investigating what can be done in this
regard
right now
If I understand correctly and the Application is discovered after
being
instantiated (and bean-wired) by Spring that would work, but that would
imply to use the getSingletons() and not the getClasses(). Otherwise,
the
services are instantiated per-request and I'll loose all the DI...
You are right
I'm getting a little confused, yes. I don't see the use of having
services
being instantiated per-request when those services normally depend on
other
services...
You can control per-request service classes in Spring with CXF
SpringResourceFactory
http://cxf.apache.org/docs/jaxrs-services-configuration.html#
JAXRSServicesConfiguration-FromSpring
Sergey
Sergey
Cheers, Sergey
Cheers.
* Melhores cumprimentos / Beir beannacht / Best regards *
*______________________________________________________*
*António Manuel dos Santos Mota <http://gplus.to/amsmota>*
*http://www.linkedin.com/in/amsmota*
<http://www.linkedin.com/in/amsmota>
*______________________________________________________*
On 26 November 2013 16:23, Sergey Beryozkin <[email protected]>
wrote:
Hi
On 26/11/13 13:41, António Mota wrote:
Hi again.
Sorry for not having explained myself correctly. What I'm trying
to do
is
to have CXF+Spring configured in a Servlet 3 "non-xml" fashion. SO
I
have
my WebApplicationInitializer initializing
a AnnotationConfigWebApplicationContext with some @Configuration
classes.
SO I have not only to instantiate the RS Applications but also all
the
Spring beans and make them available to each other. I did that with
Jersey
but found out some problems with the jersey-spring3 integration,
and
since
we're planning the use of probably Fuse (or at least Camel) I'm now
testing
CXF. I started with the example here [1] (that is indeed a example
using
the standalone container), from which i picked and adapted parts
of the
code, so I ended up in my configuration with
@Bean(destroyMethod = "shutdown")
public SpringBus cxf() {
SpringBus springBus = new SpringBus();
return springBus;
}
@Bean
public Server jaxRsServer() {
JAXRSServerFactoryBean factory =
RuntimeDelegate.getInstance().createEndpoint(restApplication(),
JAXRSServerFactoryBean.class);
factory.setServiceBean(testService());
This line appears to be redundant to me, as you are already
setting
it up
in the application. If it does not work without this line then it
is a
bug
which must be fixed.
I think we have a demo (in our distro) where a server is started
with
RuntimeDelegate, and it works
Can you double check it please ?
Thanks, Sergey
return factory.create();
}
and then the beans referring my javax.ws.rs.core.Application and my
testService. If I don't have the above 2 beans nothing is
instantiated.
To
have the TestService registered in the Application like in my
previous
post
it's irrelevant.
My servlet is configured as
ServletRegistration.Dynamic dispatcher =
container.addServlet("dispatcher","org.apache.cxf.
transport.servlet.CXFServlet");
It is working until now, but I really don't know if this is the
right
way
to do it, but nevertheless this *is* a test phase...
[1]
http://aredko.blogspot.ca/2013/01/going-rest-embedding-
jetty-with-spring.html
BTW, the @PreMatching is working now, I just had to do some small
changes
in the way ContainerRequestContext retrieves the service paths (!)
and
changed the Jersey specific HttpBasicAuthFilter to use the http
header
directly.
Cheers.
* Melhores cumprimentos / Beir beannacht / Best regards *
*______________________________________________________*
*António Manuel dos Santos Mota <http://gplus.to/amsmota>*
*http://www.linkedin.com/in/amsmota* <http://www.linkedin.com/in/
amsmota>
*______________________________________________________*
On 26 November 2013 11:39, Sergey Beryozkin <[email protected]>
wrote:
Hi
On 26/11/13 11:32, António Mota wrote:
Sorry, @PreMatching does work, after I registered it in
my javax.ws.rs.core.Application instead of rootContext.
That leads me to a question however. Why do I have to register my
classes
with the JAXRSServerFactoryBean itself and not doing it only has
the
JAX-RS
spec says, like in
@ApplicationPath("rest")
public class RestApplication extends Application {
@Override
public Set<Class<?>> getClasses() {
Set<Class<?>> s = new HashSet<Class<?>>();
s.add(TestService.class); ----------------------->
this
one I
had
to register in JAXRSServerFactoryBean
s.add(PreMatchingFilter.class);
return s;
}
}
I'm a bit confused now :-).
You can have Application activated with
CXFNonSpringJaxrsServlet, you
don't have to work with JAXRSServerFactoryBean, unless you have
you
application running in the standalone Jetty container.
What is that 'rootContext' you are referring to ? Is it something
we
need
to fix ?
Sergey
* Melhores cumprimentos / Beir beannacht / Best regards *
*______________________________________________________*
*António Manuel dos Santos Mota <http://gplus.to/amsmota>*
*http://www.linkedin.com/in/amsmota* <
http://www.linkedin.com/in/
amsmota>
*______________________________________________________*
On 26 November 2013 11:16, António Mota <[email protected]>
wrote:
Well, the services works well, however I detected some
points:
- if I point to my root address as before it still give me the
address
of
the WADLs and WSDLs. The WSDL links still work but the WADLs
give a
404
- @PreMatching does not seems to work, beside the annotated
class I
also
registered my annotated class it in the application
with rootContext.register(MyPreMatchingFilter.class);
Cheers.
* Melhores cumprimentos / Beir beannacht / Best regards *
*______________________________________________________*
*António Manuel dos Santos Mota <http://gplus.to/amsmota>*
*http://www.linkedin.com/in/amsmota* <
http://www.linkedin.com/in/
amsmota
*______________________________________________________*
On 26 November 2013 11:05, António Mota <[email protected]>
wrote:
Yes, I just found out
http://cxf.apache.org/docs/30-migration-guide.html
But the problem is, how stable is this and what's teh roadmap
until
Release? If I tell my boss to use a Milestone1 he'll laugh...
Nevertheless I will do test, I'll be happy if I can help
somehow.
Cheers.
* Melhores cumprimentos / Beir beannacht / Best regards *
*______________________________________________________*
*António Manuel dos Santos Mota <http://gplus.to/amsmota>*
*http://www.linkedin.com/in/amsmota* <
http://www.linkedin.com/in/
amsmota>
*______________________________________________________*
On 26 November 2013 11:02, Francesco Chicchiriccò <
[email protected]
wrote:
On 26/11/2013 11:58, Sergey Beryozkin wrote:
Hi,
CXF 3.0.0-milestone1 has just been released, give it a try
please
Hey, great news: I haven't heard anything yet about this
(not
even
from
announce@) and http://cxf.apache.org/download.html does not
show
anything new...
Anyway, is there any migration procedure (or just hints) for
people
upgrading from 2.7.X (2.7.8-SNAPSHOT, actually)?
Regards.
On 26/11/13 10:49, António Mota wrote:
Hi again.
As part of my POC (that ultimately is aimed at aiding us to
choose
between
CXF, CXF+Camel or Jersey) I'm now trying to port some use
cases
from
Jersey
to CXF. It was going very well except for a use case where
I'm
using
javax.ws.rs.client.ClientBuilder, but it seems that this
class
is
only
present in javax.ws.rs-api:2.0 and CXF 2.7.7 uses
javax.ws.rs-api:2.10-m10.
I tried to just import the RS 2.0 jars and it went OK until
CXF
tries
to
instantiate a ResponseImpl that uses
a javax.ws.rs.MessageProcessingException that seems to be
present
in
RS
2.0-m10 but not in 2.0.
So my question is, is there a milestone that uses the final
RS
2.0?
If
yes,
how stable is it and when it will be available as Release?
Cheers.
* Melhores cumprimentos / Beir beannacht / Best regards *
*______________________________________________________*
*António Manuel dos Santos Mota <http://gplus.to/amsmota>*
*http://www.linkedin.com/in/amsmota* <
http://www.linkedin.com/in/
amsmota>
*______________________________________________________*
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
