You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Timo Hosters <th...@orga-systems.com> on 2014/07/25 13:27:11 UTC
Question: CXF 'generate Web Service'-issue when using
"xsd:redefine"
Hi all. Another question:
The context
I have some WSDL/XSD-files defining messages/payload (let's say
something like "Person").
I must not change said files; instead I extend the messages in an
additional XSD-file (to have something like "Person with dog").
Extension is done via *XSD-redefinitions*, e. g.:
...<xs:redefine schemaLocation="./WSPayloadMessages.xsd">
<xs:complexType name="PersonType"> <xs:complexContent>
<xs:extension base="tns:PersonType"> <xs:sequence>
<xs:element name="Dog" type="animals:DogType"/>
</xs:sequence> </xs:extension>
</xs:complexContent> </xs:complexType></xs:redefine>...
Then I hand the redefinitions over to a XJC (executed by Maven) to obtain
Java classes.
The error
Once I call CXF's "java2WS" via Maven to *generate* my own *Web
Services* using the extended messages, it *fails*:
Error: java.lang.RuntimeException: java.lang.IllegalArgumentException:
*argument contains null*java.lang.RuntimeException:
java.lang.IllegalArgumentException: argument contains null at
org.apache.cxf.frontend.AbstractServiceFactory.createService(AbstractServiceFactory.java:80)
at
org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.process(JavaToWSDLProcessor.java:101)
at
org.apache.cxf.tools.java2ws.JavaToWSContainer.processWSDL(JavaToWSContainer.java:110)
at
org.apache.cxf.tools.java2ws.JavaToWSContainer.execute(JavaToWSContainer.java:75)
...
My guess
Doing some research, I concluded that CXF/JAXB has issues with the
aforementioned extension mechanism. It leads to superclasses prefixed with
"Original". However their "@XmlType"-annotations always have an empty
"name"-attribute (i. e. "*@XmlType(name = ""*, ...)"). This apparently
cause the "argument contains null"-error.
To illustrate, let's stay with the "person with dog" example:
@XmlType(name = "", propOrder = { "statusCode"})@XmlSeeAlso({
my.package.PersonType.class})@Generated(value = "com.sun.tools.xjc.Driver",
date = "2014-07-25T11:15:09+02:00", comments = "JAXB RI v2.2.7")public class
OriginalPersonType{ ... }
For testing, I manually removed the empty "name"-attribute -> the error is
gone. However I cannot do that all the time, for my projects uses Maven
and builds automatically.
How can I fix that? Or is it a bug (for it seems to work without the
"name"-attribute)? If it is a bug, I could file a bug-report.
My current configuration
I'm using:
CXF 3.0.0
Maven (from within Eclipse)
with the plugins:
maven-jaxb2-plugin : 0.9.0
jaxb2-basics : 0.6.5
cxf-java2ws-plugin : 3.0.0
Tomcat 7.0.54
Any hints are welcome. I could also provide further details (like my POM for
Maven).
--
View this message in context: http://cxf.547215.n5.nabble.com/Question-CXF-generate-Web-Service-issue-when-using-xsd-redefine-tp5746898.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Question: CXF 'generate Web Service'-issue when using
"xsd:redefine"
Posted by Timo Hosters <th...@orga-systems.com>.
Aki Yoshida-3 wrote
> 2014-08-05 14:35 GMT+02:00 Timo Hosters <
> thosters@
> >:
>> Aki Yoshida-3 wrote
>>> ... and got a fix in their microwave.
>>
>> I'm not a native speaker, thus unsure if that is colloquialism, sarcasm
>> or
>> some sort of saying? It could mean "fixing could be quick if someone
>> already
>> had an idea", I guess.
>
> me neither. But you got what I meant (this microwave 5 minutes fix
> often happens with Dan. When I start explaining about a problem,
> before I finish, he writes "got a fix". I say "wow", and 5 minutes
> later, he says "just pushed the fix to the repo". ;-)
>
> I think the fix might be easy but I can't say more without spending
> some time to look at it.
I see. Thanks for the clarification!
Aki Yoshida-3 wrote
>> The redefine idea was motivated from posts like this one
>> <http://stackoverflow.com/questions/10084145/xsd-extend-a-complex-type>
>> .
>> And it sounded to be reasonable at the time - and still does.
>
> The page also talks about this redefine being all or nothing. In
> other words, everyone has to see the new redefined schema along with
> the old one. If this is not the case, you will have problems in
> exchanging data. So, as I mentioned earlier, this redefine is used
> typically in some closed/isolated environment where this condition
> holds but not in distributed applications like web services where you
> have no control over different systems.
Understood. By now I really get the feeling it is better to reconsider and
step away from the redefine-approach.
Regards,
Timo
--
View this message in context: http://cxf.547215.n5.nabble.com/Question-CXF-generate-Web-Service-issue-when-using-xsd-redefine-tp5746898p5747814.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Question: CXF 'generate Web Service'-issue when using "xsd:redefine"
Posted by Aki Yoshida <el...@gmail.com>.
2014-08-05 14:35 GMT+02:00 Timo Hosters <th...@orga-systems.com>:
> Aki Yoshida-3 wrote
>> ... and got a fix in their microwave.
>
> I'm not a native speaker, thus unsure if that is colloquialism, sarcasm or
> some sort of saying? It could mean "fixing could be quick if someone already
> had an idea", I guess.
me neither. But you got what I meant (this microwave 5 minutes fix
often happens with Dan. When I start explaining about a problem,
before I finish, he writes "got a fix". I say "wow", and 5 minutes
later, he says "just pushed the fix to the repo". ;-)
I think the fix might be easy but I can't say more without spending
some time to look at it.
> Anyway, regarding interoperability/transform feature:These are not issues in
> our current situation: The project partner is merely keen on providing (yet
> keeping governance over) his original file. Our extended (i. e. redefined)
> file is for our Web Service component only. If the partner uses our Web
> Services, he wants (and of course has to) use the extended/redefined
> version.
> The redefine idea was motivated from posts like this one
> <http://stackoverflow.com/questions/10084145/xsd-extend-a-complex-type> .
> And it sounded to be reasonable at the time - and still does.
The page also talks about this redefine being all or nothing. In
other words, everyone has to see the new redefined schema along with
the old one. If this is not the case, you will have problems in
exchanging data. So, as I mentioned earlier, this redefine is used
typically in some closed/isolated environment where this condition
holds but not in distributed applications like web services where you
have no control over different systems.
regards, aki
> But thinking about your remark, plain type extension *could be another
> option/solution* as well. That would NOT allow to keep the complex type's
> name, but it might work too.
> Regards,
> Timo
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Question-CXF-generate-Web-Service-issue-when-using-xsd-redefine-tp5746898p5747383.html
> Sent from the cxf-user mailing list archive at Nabble.com.
Re: Question: CXF 'generate Web Service'-issue when using
"xsd:redefine"
Posted by Timo Hosters <th...@orga-systems.com>.
Aki Yoshida-3 wrote
> ... and got a fix in their microwave.
I'm not a native speaker, thus unsure if that is colloquialism, sarcasm or
some sort of saying? It could mean "fixing could be quick if someone already
had an idea", I guess.
Anyway, regarding interoperability/transform feature:These are not issues in
our current situation: The project partner is merely keen on providing (yet
keeping governance over) his original file. Our extended (i. e. redefined)
file is for our Web Service component only. If the partner uses our Web
Services, he wants (and of course has to) use the extended/redefined
version.
The redefine idea was motivated from posts like this one
<http://stackoverflow.com/questions/10084145/xsd-extend-a-complex-type> .
And it sounded to be reasonable at the time - and still does.
But thinking about your remark, plain type extension *could be another
option/solution* as well. That would NOT allow to keep the complex type's
name, but it might work too.
Regards,
Timo
--
View this message in context: http://cxf.547215.n5.nabble.com/Question-CXF-generate-Web-Service-issue-when-using-xsd-redefine-tp5746898p5747383.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Question: CXF 'generate Web Service'-issue when using "xsd:redefine"
Posted by Aki Yoshida <el...@gmail.com>.
The part that is not clear to me is how you are going to use the
instance of PersonWithDog and where? The component that has the
original Person schema will find this instance invalid because it has
the unexpected Dog element. Only those components that have the new
redefined schema can process it. This means, you will have problems
with interoperability in non-centralized applications like web
services. The redefine is just a macro to rewrite another schema for a
local modification.
If you are for the separation of concern and keep things clean,
instead of using the redefine feature that corrupts the original
schema, can you use the extend feature to define your own schema to
add the extra element that you need? In this case, there will be no
ambiguity in interpreting the old and new schemas. All instances can
be fully validated against their corresponding schema.
And regarding the transform feature, you will need it in either case
(customization via redefine or extend) when you want to achieve
interoperability between a new component creating a new instance and
sending it to another component that has only the old schema and code.
You are free to file a Jira request to log this issue. But to have
this issue fixed, you will probably need a stronger argument to
convince people that the support of redefine is important unless
someone already looked into it and got a fix in their microwave.
regards, aki
2014-08-01 16:31 GMT+02:00 Timo Hosters <th...@orga-systems.com>:
> Intention
> Aki Yoshida-3 wrote
>> I am not sure what you are intending to do.
>
> The use case would be: A project partner wants you to provide additional
> functionality (here: via a Web Service). A prerequisite is that you have to
> incorporate his already existent message definitions.
> Excursus:
> To stick with the initial Person/Dog-metaphor of this post, this would mean
> e. g.: The project partner provides you information from his
> 'Person'-database by calling the Web Service with a 'Person'-object. Using
> that, your Web Service determines suitable dogs for the person and sticks
> the according data to the 'Person'-object, leading to a
> 'PersonWithDog'-object.
> So I must not change the original definitions, but I may add to the
> definitions. The "Redefine" approach seemed to be perfect for that:
> Keep the original definitions file
> Have another file 'next to' it
> In that file: Place your extensions (using "Redefine")
> If the original definitions change (bound to happen) merely replace the
> original file and adjust the extension file - if required
> That is less trouble compared to copying the original and modifying it
> directly. (Also: See "separation of concerns"-aspect below)
> Transformation feature
> Aki Yoshida-3 wrote
>> ... CXF offers some inline transformation feature o overcome typical
>> schema incompatibility issues ...
>
> Those <https://cxf.apache.org/docs/transformationfeature.html> ? I used
> these features before, but - I have to admit - I simply did not
> consider/forgot about them for this use case. But transformation features
> *might pose another solution* for that issue. Thanks!
> Remark / separation of concerns
> However one more remark: With the "redefine"-approach, I like the
> "separation of concern" aspect. Meaning 'some other guy' with a little bit
> of XML/XSD-knowledge can handle change requests/definition updates. With the
> CXF transformation feature, that other guy needs more CXF-knowledge (and for
> my situation, I cannot rely on that unfortunately).
> I think it would be convenient if CXF could handle the "Redefine" approach.
> Would it be okay to file a change request for that?
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Question-CXF-generate-Web-Service-issue-when-using-xsd-redefine-tp5746898p5747219.html
> Sent from the cxf-user mailing list archive at Nabble.com.
Re: Question: CXF 'generate Web Service'-issue when using
"xsd:redefine"
Posted by Timo Hosters <th...@orga-systems.com>.
Intention
Aki Yoshida-3 wrote
> I am not sure what you are intending to do.
The use case would be: A project partner wants you to provide additional
functionality (here: via a Web Service). A prerequisite is that you have to
incorporate his already existent message definitions.
Excursus:
To stick with the initial Person/Dog-metaphor of this post, this would mean
e. g.: The project partner provides you information from his
'Person'-database by calling the Web Service with a 'Person'-object. Using
that, your Web Service determines suitable dogs for the person and sticks
the according data to the 'Person'-object, leading to a
'PersonWithDog'-object.
So I must not change the original definitions, but I may add to the
definitions. The "Redefine" approach seemed to be perfect for that:
Keep the original definitions file
Have another file 'next to' it
In that file: Place your extensions (using "Redefine")
If the original definitions change (bound to happen) merely replace the
original file and adjust the extension file - if required
That is less trouble compared to copying the original and modifying it
directly. (Also: See "separation of concerns"-aspect below)
Transformation feature
Aki Yoshida-3 wrote
> ... CXF offers some inline transformation feature o overcome typical
> schema incompatibility issues ...
Those <https://cxf.apache.org/docs/transformationfeature.html> ? I used
these features before, but - I have to admit - I simply did not
consider/forgot about them for this use case. But transformation features
*might pose another solution* for that issue. Thanks!
Remark / separation of concerns
However one more remark: With the "redefine"-approach, I like the
"separation of concern" aspect. Meaning 'some other guy' with a little bit
of XML/XSD-knowledge can handle change requests/definition updates. With the
CXF transformation feature, that other guy needs more CXF-knowledge (and for
my situation, I cannot rely on that unfortunately).
I think it would be convenient if CXF could handle the "Redefine" approach.
Would it be okay to file a change request for that?
--
View this message in context: http://cxf.547215.n5.nabble.com/Question-CXF-generate-Web-Service-issue-when-using-xsd-redefine-tp5746898p5747219.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Question: CXF 'generate Web Service'-issue when using "xsd:redefine"
Posted by Aki Yoshida <el...@gmail.com>.
I have never looked into whether this redefine is supported or not.
But I suppose it is not and I wonder if someone is supporting it in
the context of doing web services. The redefine construct is probably
only used by document management system people to do this sort of
modification to update the schemas.
I am not sure what you are intending to do. CXF offers some inline
transformation feature o overcome typical schema incompatibility
issues. Maybe there is another simpler way to achieve your goal
without using redefine?
regards, aki
2014-08-01 10:08 GMT+02:00 Timo Hosters <th...@orga-systems.com>:
> I have no leads how to fix this 'properly' - or whether it really is a bug.
> So for the time being, I came up with the following *interim solution:
> Manipulate the generated sources prior to compiling/CXF Web Service
> creation.*
> Accordingly, I've added another plugin to my Maven build process. After code
> generation (i. e. in Maven's "process-sources" phase), I made said plugin
> scan certain packages of the generated sources and remove the empty
> "name"-attribute tokens in question.
> The plugin is called "maven-replacer-plugin"
> <https://code.google.com/p/maven-replacer-plugin/> .
> Here an example "pom.xml"-excerpt for people who want to use aforementioned
> approach as well.
> ...<plugin>
> <groupId>com.google.code.maven-replacer-plugin</groupId>
> <artifactId>replacer</artifactId>
> <version>1.5.3</version> <executions>
> <execution> <phase>process-sources</phase>
> <goals> <goal>replace</goal>
> </goals> </execution> </executions>
> <configuration> <includes>
> <include>${basedir}/package/path/to/person/source/files</include>
> <include>${basedir}/package/path/to/other/source/files</include>
> </includes> <ignoreErrors>false</ignoreErrors>
> <regex>false</regex> <token>XmlType(name =
> "",</token> <value>XmlType(</value>
> </configuration></plugin>...
> Still: I'm unsure whether I should fill a bug report.
> And if anyone has *other ideas/solutions*, please share.
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/Question-CXF-generate-Web-Service-issue-when-using-xsd-redefine-tp5746898p5747172.html
> Sent from the cxf-user mailing list archive at Nabble.com.
Re: Question: CXF 'generate Web Service'-issue when using
"xsd:redefine"
Posted by Timo Hosters <th...@orga-systems.com>.
I have no leads how to fix this 'properly' - or whether it really is a bug.
So for the time being, I came up with the following *interim solution:
Manipulate the generated sources prior to compiling/CXF Web Service
creation.*
Accordingly, I've added another plugin to my Maven build process. After code
generation (i. e. in Maven's "process-sources" phase), I made said plugin
scan certain packages of the generated sources and remove the empty
"name"-attribute tokens in question.
The plugin is called "maven-replacer-plugin"
<https://code.google.com/p/maven-replacer-plugin/> .
Here an example "pom.xml"-excerpt for people who want to use aforementioned
approach as well.
...<plugin>
<groupId>com.google.code.maven-replacer-plugin</groupId>
<artifactId>replacer</artifactId>
<version>1.5.3</version> <executions>
<execution> <phase>process-sources</phase>
<goals> <goal>replace</goal>
</goals> </execution> </executions>
<configuration> <includes>
<include>${basedir}/package/path/to/person/source/files</include>
<include>${basedir}/package/path/to/other/source/files</include>
</includes> <ignoreErrors>false</ignoreErrors>
<regex>false</regex> <token>XmlType(name =
"",</token> <value>XmlType(</value>
</configuration></plugin>...
Still: I'm unsure whether I should fill a bug report.
And if anyone has *other ideas/solutions*, please share.
--
View this message in context: http://cxf.547215.n5.nabble.com/Question-CXF-generate-Web-Service-issue-when-using-xsd-redefine-tp5746898p5747172.html
Sent from the cxf-user mailing list archive at Nabble.com.