I have opened http://issues.apache.org/jira/browse/XMLBEANS-299 to track this, feel free to vote on it if you have a JIRA account.
You can read the description for an explanation of what the issue is, but, apart from being difficult, it will result in a perf degradation for all getters regardless of whether they actually use substitution or not (because you can't be sure _if_ substitution is being used without performing some expensive checks). So my recommendation would be to try and work around the problem by compiling the two Schemas together (or use xsi:type instead of substitution). Radu On Wed, 2006-11-29 at 09:33 +0100, Erik van Zijst wrote: > Ouch, I'm afraid that really breaks my application which relies on > others to extend elements using their own schemas and jars. > Are there any plans to fix this in an upcoming release? > > Erik > > > Radu Preotiuc-Pietro wrote: > > One thing that you should know, Erik, is that XMLBeans doesn't support > > substitution groups across jars, i.e. if you use substitution groups, > > then the "head" element and the "substitution" element have to be in the > > same jar. Seems like you may be running into this unfortunately. > > > > Radu > > > > -----Original Message----- > > From: Erik van Zijst [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, November 28, 2006 2:25 AM > > To: user@xmlbeans.apache.org > > Subject: Re: Generating partial schemas > > > > It turns out I wasn't completely accurate. > > > > When the schema of the add-on project sits in its own namespace and > > imports the schema of the main project, then xmlbeans does not download > > the main schema and compiles only the elements in the add-on schema. > > > > Alternatively, when the schema of the add-on project sits in the same > > namespace as the main project and includes the schema from the main > > project, then xmlbeans does download, process and compile the elements > > from the main project. > > > > Hence, xmlbeans appears to follow includes, but not imports. > > > > Because I want the add-on project to use its own namespace, I use > > <import>, causing xmlbeans to skip stub generation for the imported > > elements. > > > > Unfortunately, when I later try to parse an xml file that uses elements > > from both namespaces (having the generated classes of both projects in > > the classpath), xmlbeans complains the xml is not valid: > > > > [error: cvc-complex-type.2.4a: Expected element > > "[EMAIL PROTECTED]://xmlmath.org/1.0" instead of > > "[EMAIL PROTECTED]://xmlmath.org/1.0/date" here in element > > [EMAIL PROTECTED]://xmlmath.org/1.0] > > > > The above shouldn't fail as the "equals" element is declared to contain > > child elements of type "value" and element "now" extends from "value" > > (if it's helpful I can attach the schemas). > > > > I'm not sure why xmlbeans rejects the xml, but I suppose it has to do > > with the fact that the stubs from one namespace were generated > > independently from the stubs in the other namespace. > > > > regards, > > Erik van Zijst > > > > > > Erik van Zijst wrote: > >> Folks, > >> > >> I'm having a bit of trouble generating only a limited set of stub > >> classes for a set of schemas. > >> > >> I'm creating a new add-on for an existing xmlbeans-based project. This > > > >> add-on comes with its own xml schema in its own namespace that extends > > > >> data types from the main project. To this end, the add-on xsd imports > >> the main schema. > >> > >> Now the thing is that I want the add-on project to generate xmlbeans > >> stubs for the new elements only. However, because the add-on schema > >> imports the main schema, xmlbeans decides to compile stubs for the > >> main schema as well. > >> > >> Is it possible to tell xmlbeans to only compile stubs for the elements > > > >> in a specific schema and to ignore elements declared in imported and > >> included schemas? > >> > >> Ultimately I want to add the generated stubs of the new project to the > > > >> classpath as an "add-on" or "plug-in" to the main project, so the > >> stubs of both projects need to be compatible. > >> > >> regards, > >> Erik van Zijst > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > _______________________________________________________________________ > > Notice: This email message, together with any attachments, may contain > > information of BEA Systems, Inc., its subsidiaries and affiliated > > entities, that may be confidential, proprietary, copyrighted and/or > > legally privileged, and is intended solely for the use of the individual > > or entity named in this message. If you are not the intended recipient, > > and have received this message in error, please immediately return this > > by email and then delete it. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
