[
https://issues.apache.org/jira/browse/XMLBEANS-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538994#comment-17538994
]
Peter Keller edited comment on XMLBEANS-567 at 5/20/22 9:07 AM:
----------------------------------------------------------------
Many thanks for that, it is really helpful, but I am now hitting the second
problem that the OP reported, which still persists. I have uploaded a second
test case (xmlbeans-ie-tryout2.tar) where the interface extension now looks
like this:
{{package mypackage;}}
{{import java.util.List;}}
{{public interface CustomerFoo {}}
{{ String getFoo();}}
{{ List<String> getFoos();}}
{{}}}
Even though the interface and handler both import {{{}java.util.List{}}}, the
build test case now fails with:
{{Time to build schema type system: 0.942 seconds}}
{{Time to generate code: 0.078 seconds}}
{{/home/pkeller/Projects/Workflow/xmlbeans-upgrade/xmlbeans-ie-tryout2/build/java/com/example/easypo/impl/CustomerImpl.java:36:
error: cannot find symbol}}
{{public List<String> getFoos() {}}
{{^}}
{{symbol: class List}}
{{location: class CustomerImpl}}
{{1 error}}
{{BUILD FAILED}}
Declaring the return type of the handler method with the fully qualified name:
{{ public static java.util.List<String> getFoos(XmlObject xo) {}}
{{ ...}}
{{ }}}
makes the compilation work. This is a sort-of solution, but in my case that
means a lot of editing will be needed to allow me to upgrade from XMLBeans
3.1.0. Is this how it is meant to be?
An alternative approach to generating the fully qualified type (as in XMLBeans
3.1.0) would be to copy the required import statements from the handler class
definition into the generated implementation class definition.
was (Author: pakeller):
Many thanks for that, it is really helpful, but I am now hitting the second
problem that the OP reported, which still persists. I have uploaded a second
test case (xmlbeans-ie-tryout2.tar) where the interface extension now looks
like this:
{{package mypackage;}}
{{import java.util.List;}}
{{public interface CustomerFoo {}}
{{ String getFoo();}}
{{ List<String> getFoos();}}
{{}}}
Even though the interface and handler both import {{{}java.util.List{}}}, the
build test case now fails with:
{{Time to build schema type system: 0.942 seconds}}
{{Time to generate code: 0.078 seconds}}
{{/home/pkeller/Projects/Workflow/xmlbeans-upgrade/xmlbeans-ie-tryout2/build/java/com/example/easypo/impl/CustomerImpl.java:36:
error: cannot find symbol}}
{{public List<String> getFoos() {}}
{{^}}
{{symbol: class List}}
{{location: class CustomerImpl}}
{{1 error}}
{{BUILD FAILED}}
Declaring the interface and handler methods with the fully qualified name as:
{{ java.util.List<String> getFoos();}}
and:
{{ public static java.util.List<String> getFoos(XmlObject xo) {}}
{{ ...}}
{{ }}}
makes the compilation work. This is a sort-of solution, but in my case that
means a lot of editing will be needed to allow me to upgrade from XMLBeans
3.1.0. Is this how it is meant to be?
> Problems with XMLBeans Extension Interfaces Feature
> ---------------------------------------------------
>
> Key: XMLBEANS-567
> URL: https://issues.apache.org/jira/browse/XMLBEANS-567
> Project: XMLBeans
> Issue Type: Task
> Affects Versions: Version 5.0.0
> Reporter: Dmitry Lastochkin
> Priority: Major
> Attachments: xmlbeans-ie-tryout.tar, xmlbeans-ie-tryout2.tar
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello! In our project we are using [XMLBeans Extension Interfaces
> Feature|https://cwiki.apache.org/confluence/display/XMLBEANS/ExtensionInterfacesFeature].
> When we compile the TypeSystem (using {{SchemaTypeSystemCompiler.compile}}),
> we add the jar with our extension classes to classpath parameter. In XMLBeans
> 2.4 it works perfectly. But when we updated to XMLBeans 5.0.0, we encountered
> the following error during an extensions validation:
> {code}
> Interface 'SomeInterface' not found."
> {code}
> As far as I understand, this is because
> {{org.apache.xmlbeans.impl.config.Parser}} does not search classes in
> classpath (only in files).
> When we added the sources of the extension interface to the parameters,
> TypeSystem compiled successfuly. But then we ran into another problem. When
> XMLBeans generates java files from XSD, it uses simple class names (instead
> of fully qualified names as it was in XMLBeans 2.4.0) for the classes that
> are used in methods of the extension interface (like parameters types or
> return types). And therefore the geneted files cannot be compiled if the
> extension classes are in a different package.
> Are those changes (ingorning classpath when searching for extenstions and
> using simple names for extenstion classes in code generation instead of fully
> qualified names) were made intentionally? Such limitations are hard to work
> around, making an upgrade from older XMLBeans version very complicated.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
