Hi
As far as I know annotations at the interface level will only supported in the
0.7 version (it's mandated in the corresponding version of the spec), and only
method-level annotations will be inherited (I'll need to confirm it), Jersey
does it on the current trunk (which is corresponds to
Not unless it's enabled by default. I'll look into it. Thanks.
Benson Margulies-4 wrote:
Did you enable validation?
On Fri, Apr 4, 2008 at 4:30 PM, Web Man [EMAIL PROTECTED] wrote:
When a SOAP request is submitted without the closing /soapenv:Envelope,
the
Web Service is called
On Monday 07 April 2008, Web Man wrote:
Not unless it's enabled by default. I'll look into it. Thanks.
It's probably not worth your time. I'm almost positive that nothing in
the cxf code even bothers to read the closing body/envelope tags.
Tracing through the interceptors, there is
I'm creating a web service that needs to do some processing that will
take too long to perform and return to the client synchronously. I'm
considering giving the client back a transactionid immediately, storing
it in a database, then spawning a thread which will do the long running
task and
Should work just fine, especially if you only rely on jax-ws or
somesuch interface for communicating with the outside world. That is
to say, if you don't work directly with the CXF innards such as the
bus, the exchange and interceptors, during your concurrent execution -
not that I don't think
If that is the case, that means CXF is not the problem, it is some
deployment option of Weblogic (i.e., you would have the same problem
with *any* web application deployed on it, web services or graphical web
app.)
What I would do is skeletonize your web application (remove CXF and
everything
Everything I can think of really has nothing to do with CXF.
1) Timestamp on the war/ear is from a computer that has it's clock set
wrong. Basically, if the war is built in the future according to the
machine running weblogic, it might think the war has changed when it
really hasn't.
2)
Brad,
It's quite possible (and highly likely) that the JAXB context is not
being created with the subclasses as part of the context. Thus, the
subclasses cannot be properly written/read. By default, the runtime
just examines the exact classes referenced from the SEI interface to
figure
Hi all,
I developed a REST web service using CXF's http binding, and I have no
problem at all with the object marshaling or the reading of the XML
outputs. I now need to get JSON output from the same web service, so I
configured a new ws endpoint in spring, which will return the JSON in the
Benson,
Thank you for resolving the issue I logged so quickly.
I'm guessing it is available in the trunk? (if not, I can wait till the next
snapshot)
thanks again!
Judes
On 4/6/08, Benson Margulies [EMAIL PROTECTED] wrote:
Aegis does not support unqualified schema. However, it should have
Hmm Looks like the axis client isn't sending a SOAPAction header
like it's supposed too. That said, we should be a bit more defensive
in that interceptor. We check if the action is an empty string, but we
don't check if it's null. I'll update the interceptor to do that.
Dan
On
Hi,
We are trying to deploy our CXF application on WebSphere 6.1 and we see
the following problem
ServletWrappe E SRVE0100E: Did not realize init() exception thrown by
servlet cxf: org.springframework.beans.factory.BeanCreationException:
Error creating bean with name
Sergey,
It appears that putting the annotations on the implementation class
(rather than the interface) resolved the path issues. You are right,
apparently interface annotations are not supported. I really hope that
these are supported in the future. However, I am still not out of the
Never mind on this.got it all worked out now. THANK YOU big time
to the gents copied (and Daniel) for your advice. It would be great to
get some of this stuff in a doc somewhere. Here was my winning formula:
- Java 1.6.x
- CXF 2.1-incubator-snapshot
- Do not annotate interfaces, but
Hi,
I used wsdl2java and it created several .java files. I noticed that nullable
elements are created as JAXBElementtype, while non-nullable elements are
classes without JAXBElement wrappers (Integer, etc).
What is the rationale behind this? Is there documentation on why this is done,
and
15 matches
Mail list logo
