Well, URI.resolve won't work correctly without a trailing slash. Hmm...
I will need to investigate it further
Sergey
On 29/11/13 10:02, Sergey Beryozkin wrote:
Hi António
On 28/11/13 15:18, António Mota wrote:
Yes, I just checked again. I don't know if it matters, but I'm getting
the requestContext from a filter
public void filter(ContainerRequestContext requestContext) throws
IOException {
String fromPath =
requestContext.getUriInfo().getBaseUri().toString();
String pathInfo =
requestContext.getUriInfo().getAbsolutePath().toString();
This is one of those grey areas in the spec/API. I do not see anything
in UriInfo documentation suggesting that a base URI has to end with the
trailing slash, it seems not quite right to me, though, to be honest, both
http://www.bar.com
and
http://www.bar.com/
both qualify well as base URIs.
I'm not sure why Jersey adds a trailing slash, one theory can be that it
is done so that it can concatenate literally with the root resource's
Path value, example,
@Path("foo")
public class MyRoot {
}
so if you have
http://www.bar.com/
then it will concatenate as is with "foo".
This is a theory though.
The developers are not expected to do such kind of calculations
manually, UriInfo.getBaseUriBuilder() needs to be used if the base URI
will be used to build some other link, etc, or even do
UriInfo.getBaseUri().resolve("foo"), in either case the issue of
ensuring a proper path segment separator is added (or not) will be taken
care of.
Purely from the reporting point of view, IMHO "http://www.bar.com"; reads
a little bit better than the version with the trailing slash, but it is
really a minor issue; I will open a spec request to clarify how the base
URI is expected to be calculated but I think the maximum we can get
there is a *recommendation* on the use of the trailing slash as opposed
to a *requirement*
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 28 November 2013 11:37, Sergey Beryozkin <[email protected]> wrote:
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
