Yana, I haven't created a patch for that. Below (and as an attachment) you can find the modified method... We were reviewing the code in several points and we think that's the better point (at least the better point we've seen) to insert the change, because this is the point called when XMLBeans is traversing the tree (and therefore building XMLObjects when required). That's important because we need the same behaviour for the different data views (i.e. DOM, Cursor, XMLObject).
In that point, the strategy was: if we're coming from NO_TYPE, don't check
for further types... now, we're checking every time...
Before: (isSimpleType() || !containsElements() || isNoType())
After: type==null && (isSimpleType() || !containsElements() || isNoType())
Mainly the strategy is as follows
*Obtain the context type loader and check if the element we're going to
create is known to the SchemaTypeLoader
*If the type is found, go on processing with that type...
Obviously, it would be very nice if you can review this code and add your
great expertise, as this is a *VERY* nuclear XMLBeans part (maybe we're
missing any point... efficiency, incorrect in any situation, ...). Also we
don't know if the ContextTypeLoader is our better option...
We're working now with that changes without problems, and getting the right
behaviour (in all cases, i.e. while traversing the tree in the several views
(XMLObject, Cursor, DOM,...) even when executing XPath/XQuery...). We get
the right types (I think that's because of the point where the change is
made), so, no need for changeType().
By the way, we're experiencing another *huge* problem with XMLBeans'
namespace prefix handling, as XMLBeans only calculates / puts the namespace
prefixes when saving... and that's a huge problem in applications that need
to make calculations (i.e. digital signatures) against parts of the document
before saving, because XMLBeans modify the document when saving (the
"signed" version is different from the "saved" version, so the signature
gets broken from the first moment...).
We've resolved this problem manually for the moment (using a recursive
algorithm that puts prefixes to the elements), but, is there any better way
to do that??. Have you ever considered this point?.
Thanks in advance,
Carlos
/* These two methods, createElementType and getElementType have to stay
* synchronized, because they create an XmlObject and return the type
* for that object, respectively. But since they do slightly different
* things, they can't be refactored to share code, so exercise caution
*/
public XmlObject createElementType(QName eltName, QName xsiType,
SchemaTypeLoader wildcardTypeLoader)
{
SchemaType type = null;
SchemaProperty prop = null;
SchemaTypeLoader loader=XmlBeans.getContextTypeLoader();
if (loader!=null){
SchemaGlobalElement element=loader.findElement(eltName);
if (element!=null){
type=element.getType();
}
}
if (type==null && (isSimpleType() || !containsElements() ||
isNoType()))
{
type = BuiltinSchemaTypeSystem.ST_NO_TYPE;
}
else
{
prop = (SchemaProperty)_propertyModelByElementName.get(eltName);
if (prop != null)
{
type = prop.getType();
}
else if (_typedWildcardElements.contains(eltName) ||
_validSubstitutions.contains(eltName) || type!=null)
{
SchemaGlobalElement elt =
wildcardTypeLoader.findElement(eltName);
if (elt != null)
{
type = elt.getType();
SchemaType docType =
wildcardTypeLoader.findDocumentType(eltName);
if (docType != null)
prop = docType.getElementProperty(eltName);
}
else
type = BuiltinSchemaTypeSystem.ST_NO_TYPE;
}
else
{
// Check if the requested element isn't by any chance part
of a
// substitution group headed by one of the declared elements
// Better not enable this yet
/*
SchemaGlobalElement elt =
wildcardTypeLoader.findElement(eltName);
SchemaGlobalElement sghead = elt == null ? null :
elt.substitutionGroup();
while (sghead != null)
{
if
(_propertyModelByElementName.containsKey(sghead.getName()))
{
type = elt.getType();
SchemaType docType =
wildcardTypeLoader.findDocumentType(elt.getName());
if (docType != null)
prop =
docType.getElementProperty(elt.getName());
break;
}
sghead = sghead.substitutionGroup();
}
*/
if (type == null)
type = BuiltinSchemaTypeSystem.ST_NO_TYPE;
}
if (xsiType != null)
{
SchemaType itype = wildcardTypeLoader.findType(xsiType);
// NOTE: a previous version of XMLBeans used ST_NO_TYPE if
the
// xsiType was not derived from 'type', but this results in
a
// ClassCastException. Instead we ignore xsi:type if it's
not
// found or a derived type.
if (itype != null && type.isAssignableFrom(itype)) {
type = itype;
}
}
}
if (type != null)
return ((SchemaTypeImpl)type).createUnattachedNode(prop);
return null;
}
Carlos González-Cadenas
Director Tècnic, DirecTrust
Technical Director, DirecTrust
netfocus
Diagonal 188-198 Planta 2
08018 Barcelona
tel: 902 303 393
fax: 902 303 394
[EMAIL PROTECTED]
www.netfocus.es
-----Mensaje original-----
De: Yana Kadiyska [mailto:[EMAIL PROTECTED]
Enviado el: martes, 29 de noviembre de 2005 20:23
Para: [email protected]; [EMAIL PROTECTED]
Asunto: RE: Select path typing behavior ?
Thanks Carlos,
I understand the setup now -- this is correct, if the XmlObject was untyped
prior to the query, you will need to change the type by calling changeType
but this will not work unless the type is not a document type.
I am not sure that createElementType is the right place to make the change,
I will think about it (I am not too familiar with that code). Do you have a
patch implementing that change? If so, could you please submit it for
consideration? (you can attach it to Jira 161 or reply to this email and
I'll attach it) This way it won't get lost.
Thanks, Yana
-----Original Message-----
From: Carlos González-Cadenas [mailto:[EMAIL PROTECTED]
Sent: Monday, November 28, 2005 12:10 PM
To: [email protected]
Cc: 'David Garcia'
Subject: RE: Select path typing behavior ?
Jean-Christophe,
If you're looking for a SignatureTemplate enveloped into another document
whose schema is not known for XMLBeans (i.e a SignatureTemplate as a child
of another document), the XPath will get you to the correct element, but
this element's type is unknown for XMLBeans (even when you have a compiled
schema for it), as XMLBeans assume that inside an unknown document cannot be
known elements (the reality is that XMLBeans knows that type but ignores
it).
The schemaType approach will not work for the element(not implemented) (only
works for documents... where I think there's no problem, because if the
document's schema is known, XMLBeans gets to the right type without
problems...)
This behaviour (the one described in the first paragraph) is located in the
method
public XmlObject createElementType(QName eltName, QName xsiType,
SchemaTypeLoader wildcardTypeLoader)
of the org.apache.xmlbeans.impl.schema.SchemaTypeImpl class.
You can easily circumvent this behaviour (we needed to do so in order to get
things working...) by taking a look at this class and modifying accordingly.
After that, XMLBeans will work as expected (well, at least as expected for
me... ;))
Yana:
Can you consider whether this change is appropriate for XMLBeans or not?. We
would like to discuss the changes if you're interested...
Kind regards,
Carlos
Carlos González-Cadenas
Director Tècnic, DirecTrust
Technical Director, DirecTrust
netfocus
Diagonal 188-198 Planta 2
08018 Barcelona
tel: 902 303 393
fax: 902 303 394
[EMAIL PROTECTED]
www.netfocus.es
-----Mensaje original-----
De: Yana Kadiyska [mailto:[EMAIL PROTECTED]
Enviado el: lunes, 28 de noviembre de 2005 20:47
Para: [email protected]
Asunto: RE: Select path typing behavior ?
Hm...could you send a small repro (query, instance and schema) so I can
take a look? It is odd that you need to use changeType to begin with as
selectPath should return the original object in your instance which
should already have the correct type. This issue aside, changeType will
not work if the type you're changing to is not a document type. (I have
a suspicion you're using a well known schema but can't find the
definition of SignatureTemplate)
--Yana
-----Original Message-----
From: Jean-Christophe Pazzaglia
[mailto:[EMAIL PROTECTED]
Sent: Monday, November 28, 2005 11:30 AM
To: [EMAIL PROTECTED]
Subject: Select path typing behavior ?
Hi,
I do have a problem casting a selctPath to its proper type
(cannot cast XMLAnyTypeImpl to SignatureTemplateType)
while using :
SignatureTemplateType c=(SignatureTemplateType)
documentToSign.selectPath("declare namespace
msig='http://www.eurecom.fr/security/msig#';" +
"$this//msig:[EMAIL PROTECTED]'ID000004']")[0]
Further investigating I tried that :
documentToSign.selectPath("declare namespace
msig='http://www.eurecom.fr/security/msig#';" +
"$this//msig:[EMAIL PROTECTED]'ID000004']")
=>
[<xml-fragment name="ID000004"
xmlns:xhtml="http://www.w3.org/1999/xhtml";
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:msig="http://www.eurecom.fr/security/msig#";>
<!-- Valid SignatureTemplateType children .. -->
</xml-fragment> ]
documentToSign.selectPath("declare namespace
msig='http://www.eurecom.fr/security/msig#';" +
"$this//msig:[EMAIL PROTECTED]'ID000004']/..")
=>result
[<xml-fragment xmlns:xhtml="http://www.w3.org/1999/xhtml";
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xmlns:msig="http://www.eurecom.fr/security/msig#";>
<msig:SignatureTemplate name="ID000004">
<!-- Valid SignatureTemplateType children .. -->
]
I tried also that without success :
SignatureTemplateType c=(SignatureTemplateType)
documentToSign.selectPath("declare namespace
msig='http://www.eurecom.fr/security/msig#';" +
"$this//msig:[EMAIL PROTECTED]'"+signatureTemplateReference+"']")
[0].changeType(SignatureTemplateType.type);
NB: the result of change type is the original object and not null ...
any clues ?
jc
PS: I am using the release 2.1
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
createElementType.java
Description: Binary data
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
