|
RE: Another problem with missing schema types (v1): msg#00109text.xml.xmlbeans.user
I remember making what I think is the fix for this problem in the V2 codebase and not being the easy one. If using V2 is not an option, I'll have to go back and see what it would take to port the fix over. Radu -----Original Message----- From: David Jencks [mailto:david_jencks@xxxxxxxxx] Sent: Tuesday, January 18, 2005 2:45 PM To: user@xxxxxxxxxxxxxxxxxxx Subject: Another problem with missing schema types (v1) A long time ago I had a problem using xmlbeans on the j2ee 1.4 schemas from sun since they had duplicate uniqueness constraint names, as Radu very kindly pointed out. Eventually Sun fixed the schemas and all seemed well. However, I've just come across what may be a related problem that I don't think can be blamed on Sun so easily. The j2ee_web_services_client_1_1.xsd has this group: <xsd:group name="service-refGroup"> <xsd:sequence> <xsd:element name="service-ref" type="j2ee:service-refType" minOccurs="0" maxOccurs="unbounded"> <xsd:key name="service-ref_handler-name-key"> <xsd:annotation> <xsd:documentation> Defines the name of the handler. The name must be unique within the module. </xsd:documentation> </xsd:annotation> <xsd:selector xpath="j2ee:handler"/> <xsd:field xpath="j2ee:handler-name"/> </xsd:key> </xsd:element> </xsd:sequence> </xsd:group> As you can see, this is a key inside a group. The group eventually gets used in 5 places (3 ejbs, web-app, and app-client). Compiling all the schemas with xmlbeans appears to go fine, and I end up with a schema type named like this: schema.system.s36B98A072B910FA7209F8F5FBD7FF0A3.servicerefhandlernamekey identityconstraint5 However, when I attempt to validate a web.xml containing a service-ref, it looks for schema.system.s36B98A072B910FA7209F8F5FBD7FF0A3.servicerefhandlernamekey identityconstraint4 which is not present, so validation fails. org.apache.xmlbeans.SchemaTypeLoaderException: XML-BEANS compiled schema: Could not locate compiled schema resource schema/system/s36B98A072B910FA7209F8F5FBD7FF0A3/ servicerefhandlernamekeyidentityconstraint4.xsb (schema.system.s36B98A072B910FA7209F8F5FBD7FF0A3.servicerefhandlernameke yidentityconstraint4) - code 0 at org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.<init>(Sc hemaTypeSystemImpl.java:1110) at org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.resolveHandle(Schem aTypeSystemImpl.java:2876) at org.apache.xmlbeans.SchemaComponent$Ref.getComponent(SchemaComponent.jav a:137) at org.apache.xmlbeans.SchemaIdentityConstraint$Ref.get(SchemaIdentityConst raint.java:130) at org.apache.xmlbeans.impl.schema.SchemaLocalElementImpl.getIdentityConstr aints(SchemaLocalElementImpl.java:132) at org.apache.xmlbeans.impl.validator.Validator.beginEvent(Validator.java: 540) at org.apache.xmlbeans.impl.validator.Validator.nextEvent(Validator.java: 223) at org.apache.xmlbeans.impl.store.Saver$ValidatorSaver.emitEvent(Saver.java :3800) at org.apache.xmlbeans.impl.store.Saver$ValidatorSaver.emitEvent(Saver.java :3763) at org.apache.xmlbeans.impl.store.Saver$ValidatorSaver.emitContainer(Saver. java:3685) at org.apache.xmlbeans.impl.store.Saver.processContainer(Saver.java:818) at org.apache.xmlbeans.impl.store.Saver.process(Saver.java:561) at org.apache.xmlbeans.impl.store.Saver$ValidatorSaver.<init>(Saver.java: 3589) at org.apache.xmlbeans.impl.store.Type.validate(Type.java:321) at org.apache.xmlbeans.impl.values.XmlObjectBase.validate(XmlObjectBase.jav a:351) I'm speculating that xmlbeans is in some sense replacing each group usage with a copy of its contents, thus effectively generating 5 keys with the same name. So, my questions are, 1. Is this a bug in xmlbeans v1, or is there something wrong with the sun schema? 2. Should it work in v2? Many thanks, david jencks --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@xxxxxxxxxxxxxxxxxxx For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxx |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Another problem with missing schema types (v1): 00109, David Jencks |
|---|---|
| Next by Date: | Re: Another problem with missing schema types (v1): 00109, David Jencks |
| Previous by Thread: | Another problem with missing schema types (v1)i: 00109, David Jencks |
| Next by Thread: | Re: Another problem with missing schema types (v1): 00109, David Jencks |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |