Reading the code of JAXB, I see that it purports to accept a customization
with no schemaLocation, so I tried just removing the code in
CustomizationParser that forced in the wsdlURL. Now JAXB complains on this
case (testReuseJabBindingFile) that the XPath doesn't find anything. Perhaps
the case is
Consider CodeGenBugTest.testReuseJabBindingFile1.
This is a jaxb binding customization file with no schemaLocation at all. So
we substitute the wsdl location. And, in the code as currently on trunk, all
the wsdl files are 'keyed' by the wsdl URL, not the schema URL.
If I cause files to be keyed b
You've definitely hit a bug. Can you file a JIRA and attach the wsdl's so I
don't forget about it?
Thanks!
Dan
On Thu March 26 2009 3:26:25 pm Tyler Wilson wrote:
> Here's the new set. (I just changed the names of the porttypedef
> files.)
>
> While I can generate the source code, it fails t
Hi David
I agree. CXF 2.2.1 should not be far away - perhaps in 4 weeks or 5 weeks but with the TCK work 'looming' I'd probably not want to
ask you to postpone a release and find myself telling you later on ' I won't make it :-)'. DOSGI users do need a release so I agree
with what you suggested
Great to hear about the JAXRS component for DOSGi, Sergey!
What is the expected release timeframe of CXF 2.2.1?
If its a bit further out, why not do a DOSGi 1.0 release based on CXF
2.2 and then do another 1.1 release with the JAXRS stuff as soon as
2.2.1 is out?
Cheers,
David
2009/3/26 Sergey
Here's the new set. (I just changed the names of the porttypedef
files.)
While I can generate the source code, it fails to compile in JBuilder
with the following errors (both using jdk 1.5 and 1.6):
"package-info.java": Source
D:\TylerJProjects\WS-NotificationClient\src\org\apache\cxf\ws\address
Further complexity is the binding files. Binding files have schemaLocation
attributes. JAXB does not resolve those. We can pre-resolve those, in fact,
my not-yet-checked in attempt does so.
My view of the big picture is this. We currently, precariously, arrange
consistent behavior from wsdl4j read
On Tue March 24 2009 11:33:04 am Rao, Sameer V wrote:
> I was looking at the JAXBDataBinding class
> (cxf-tools-wsdlto-databinding-jaxb) and was not sure of the following-
>
> 1. We are building Options used by SchemaCompiler and calling its
> parseArgument(). However, values passed through that ar
On Sat March 21 2009 1:16:00 pm Benson Margulies wrote:
> Is it my imagination, or is bus-extension.xml obsolete?
No. It's used by the non-spring bus to load stuff. Without it, everything
would require spring for all use cases.
--
Daniel Kulp
dk...@apache.org
http://www.dankulp.com/blog
The wsdl's did not survive the Apache filters. I did find them in the pre-
moderated emails though.
In THAT case, the issue is that the porttypedef.wsdl file defines the
porttype for:
portType name="NotificationBroker"
but the CreatePullPoint.wsdl is looking for:
type="wsntw:CreatePullPoi
Hi,
I'm quite keen to emded a JAXRS component into DOSGI as I reckon we now have all the pieces in place (proxy based client api
support, and Benson's Aegis provider) so it should, fingers crossed, be a fairly straighforward exercise - but then you never know
what could actually happen at the d
Hi David,
On the general point, I definitely agree that we need to be thinking about a
1.0 release.
On the specifics ...
> * We need to make sure that all the API's we are using are exactly
> correct with the lasted RFC 119 version, e.g. I think we need to add
> something to the ServicePublicati
Hi all,
Since CXF 2.2 is out now I was thinking about what work needs to be
done for a DOSGi 1.0 release.
I've just updated the poms to depend on CXF 2.2, but there's still a
few things to do...
* there is CXF-1966. It would be good to get a solution to this. I
heard that Spring-DM 1.2.0 is goin
13 matches
Mail list logo
