+1
On Saturday 18 October 2008 11:19:14 am Willem Jiang wrote:
Once again, there have been a bunch of bug fixes and enhancements that
have been done compared to the 2.1.2 release. Over 52 JIRA issues
are resolved for 2.1.3.
List of issues:
https://issues.apache.org/jira/browse/CXF/fixforver
+1,
-- Ulhas
Willem Jiang wrote:
Once again, there have been a bunch of bug fixes and enhancements that
have been done compared to the 2.1.2 release. Over 52 JIRA issues
are resolved for 2.1.3.
List of issues:
https://issues.apache.org/jira/browse/CXF/fixforversion/12313354
The staging area
+1
On Sat, Oct 18, 2008 at 5:19 PM, Willem Jiang <[EMAIL PROTECTED]> wrote:
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to the 2.1.2 release. Over 52 JIRA issues
> are resolved for 2.1.3.
>
> List of issues:
> https://issues.apache.org/jir
+1
> -Original Message-
> From: Willem Jiang [mailto:[EMAIL PROTECTED]
> Sent: 18 October 2008 16:19
> To: dev@cxf.apache.org
> Subject: [VOTE] Release Apache CXF 2.1.3 (2nd try)
>
>
>
> Once again, there have been a bunch of bug fixes and enhancements that
> have been done compared to
Hi,
I'm getting into trouble here now that I'm debugging a test case.
readFrom takes Class, not Class. I don't see how the JAXB
code could work, as it will try to obtain a type for 'Object.class',
Unfortunately Class does not compile. Plain Class is passed in to it from above and it has all t
The abstract providers (JAXB and Aegis) are declared as subclasses of
MessageBodyReader, not MessageBodyReader. That in turn
forces the parameter to be readFrom(Class type, ...), which
requires the input to be the one and only Object.class object.
I don't see how you can assert that JAXB works wh
+1
On Tue, Oct 21, 2008 at 4:34 AM, Sergey Beryozkin
<[EMAIL PROTECTED]> wrote:
> +1
>
>>
>> On Saturday 18 October 2008 11:19:14 am Willem Jiang wrote:
>>>
>>> Once again, there have been a bunch of bug fixes and enhancements that
>>> have been done compared to the 2.1.2 release. Over 52 JIRA i
Is it possible to get hold of the objects that are automatically built by CXF
from the definition in cxf.xml?
I have an endpoint in cxf.xml:
I have left out the address and the wsdl on purpose, because these are not
static, but retrieved from a separate configuration manager. I
The abstract providers (JAXB and Aegis) are declared as subclasses of
MessageBodyReader, not MessageBodyReader. That in turn
forces the parameter to be readFrom(Class type, ...), which
requires the input to be the one and only Object.class object.
Extending from MessageBodyReader ? What does
I'll try the experiment with the breakpoint again.
The API of MessageBodyReader suggests to me that, indeed, it expects
end-programmers to declare things like:
MessageBodyReader r = new SomeProviderOrAnother();
MyClass x = r.readFrom(MyClass.class, )
I want to look at the spec to see if its
I have a wsdl and set of associated XSD files (attached) that causes the
javax.xml.ws.Service within CXF to hang within it's constructor.
All I do is make the call:
CDAService cdaService = new CDAService(wsdlURL, new QName(cdaNamespace,
cdaServiceName));
CDAService extends javax.xml.ws.Service
The RI/required section of the 1.0 FR calls for a MessageBodyReader
that delivers JAXBElements! In other words, they aren't really
thinking about delivering arbitrary Java objects. Since putting
@Provider on a generic class is likely to prove chaotic (or maybe it
just works), I'm not quite sure wha
Hi all,
I've added a new Spring-DM based demo for the Distributed OSGi stuff
to https://issues.apache.org/jira/browse/CXF-1879
Cheers,
David
Hi,
First the good news - I heroically :-) fixed the AegisTest by adding a plain old cast when passing AegisTestBean.class and your
provider works perfectly well. This is how it works for JAXB too.
The RI/required section of the 1.0 FR calls for a MessageBodyReader
that delivers JAXBElements
Do you participate in the JSR Process for this thing? As the FR
stands, @Provider seems to be required.
The cast is really ugly.
I'd be inclined to at least add a GenericAegisProvider that would
allow a user to avoid the cast. Adding the property thing we discussed
before and having the user pass
Hi,
I'm seeing this compilation problem on 2.1.4-SNAPSHOT :
[INFO] ---
[INFO] Building Apache CXF Command Line Tools WSDLTo JAXWS Frontend
[INFO]task-segment: [install]
[INFO] -
Hi
Do you participate in the JSR Process for this thing? As the FR
stands, @Provider seems to be required.
I don't participate - I started working with our JAX-RS impl at the time it was
at 0.5 or 0.4 level.
I'm asking questions though periodically.
@Provider is needed only if a CXF user wh
OK, here's the problem. I don't know how providers actually get used
in the real code. I guess it's time to clone the systest and see how
it comes out.
On Tue, Oct 21, 2008 at 1:15 PM, Sergey Beryozkin
<[EMAIL PROTECTED]> wrote:
> Hi
>
>
>> Do you participate in the JSR Process for this thing? As
OK, here's the problem. I don't know how providers actually get used
in the real code. I guess it's time to clone the systest and see how
it comes out.
You won't see then in the actual system tests. Actually, there're custom providers there, but they're registered from Spring and
that's the
The question lurking here is the official API of the
MessageBodyReader. How does the interceptor choose the right class to
pass to it?
On Tue, Oct 21, 2008 at 1:26 PM, Sergey Beryozkin
<[EMAIL PROTECTED]> wrote:
>
>
>> OK, here's the problem. I don't know how providers actually get used
>> in the
+1
On Tue, Oct 21, 2008 at 1:19 PM, Benson Margulies <[EMAIL PROTECTED]>wrote:
> +1
>
> On Tue, Oct 21, 2008 at 4:34 AM, Sergey Beryozkin
> <[EMAIL PROTECTED]> wrote:
> > +1
> >
> >>
> >> On Saturday 18 October 2008 11:19:14 am Willem Jiang wrote:
> >>>
> >>> Once again, there have been a bunch o
Hi Sergey,
I didn't get the error that you met.
Did you try to remove the geronimo-ws-metadata_2.0_spec-1.1.2.jar from
the maven repo
org\apache\geronimo\specs\geronimo-ws-metadata_2.0_spec\1.1.2 and run
the build again?
Willem
Sergey Beryozkin wrote:
> Hi,
>
> I'm seeing this compilation probl
We have 12 +1 votes , 10 PMC binding
+1 PMC: wjiang, ffang, eglynn, jjagielski, dkulp, sberyozkin, ubhole,
gnodet, seanoc, bmargulies
+1 Committer: cshneider
+1 Other: dsantosh
Thus, this vote passes. I'll try to get the artifacts published today.
Willem
23 matches
Mail list logo
