Christian,
I constructed a similar service (with CXF 2.4.4) for a Tomcat 7 deployment
- ran the profile software and .. only one instance - similarily with
Glassfish 2.1. I guess this means that it may be an issue with Glassfish
3.1?
Marcus
On Sun, Dec 11, 2011 at 1:28 AM, Christian Schneider <
Ok, finally found out where the bug is. The key was in the line:
at
com.myapp.data.Base$JaxbAccessorM_getId_setId_java_lang_Object.set(MethodAccessor_Ref.java:56)
I actually had a Base data object like so:
@MappedSuperclass
abstract public class Base implements Serializable {
public ab
Hi,
I didn't want to treat it as JSON returned for all requests with
{entity}.json
If that's not possible, I would atleast like to know how I can identify
that contains .json in:
RequestHandler.handleRequest(Message m, ClassResourceInfo resourceClass)
Since when I use message.get(Message.REQUE
Hi
On 09/12/11 22:01, eswarup wrote:
Hi,
We've case where .json is getting considered as JSON output which either I
would like to restrict it or be able to identify it using one of Message
properties
for e.g.
@Path("/getProfile/{guid}/")
/getProfile/madonna.json treats it as JSON output and
Where should this be added?
It seems that the port not found error happens when the constructor runs
super.
Also service.addPort() needs bindingId.
Is this required or can it be null.
If yes what is it exactly.
Thank you.
--
View this message in context:
http://cxf.547215.n5.nabble.com/javax-xm
Hi
On 09/12/11 18:19, Rice Yeh wrote:
Hi,
I just find that there are many threads serve a http request. My case
jaxrs and I find that threads running the interceptor.handleMessage,
resource code, interceptor.handleFault and exception mapper are not same.
This makes thread local variables canno
That looks all very normal. Using this setup you should normally get
only one instance.
Btw as your config does not seem to be special for glassfish you might
try to deploy your war to a simple tomcat and see how it reacts.
If you get only one instance on tomcat then your config should be all
Update: we are using Jackson on the server (the only thing that worked for us
in OSGi).
Using Jackson at the client as well solved this issue. There is no apparent
need to indicate any client settings in that case, and the json is unmarshalled
ok.
Guy
On 8-dec-2011, at 10:06, Guy Pardon wro
Christian,
I will try to recreate the issue in a new build environment - although I am
also seeing the same issue with other test systems. The CXF segments of
web.xml are:
Apache CXF Endpoint
cxf
cxf
org.apache.cxf.transport.servlet.CXFServlet
1
cxf
/services/*
