Fuhwei,
I've been encountering a similar problem using dynamic data objects, and
although I haven't yet fully absorbed the detail of your problem in the
generated space I thought I'd sharethe solution to my problem, as I think
it may have a bearing on yours.
My problem was that in order to generate types from an XSD which include an
element of type commonj.sdo.ChangeSummaryType (or any other
commonj.sdotype) a schema writer would naturally include an import of
sdoModel.xsd. The net effect of this is that after the conversion of the
users schema, a new dynamic version of the SDO types exist, masking those
generated by the static initialisation of ModelPackageImpl, containing
generated versions of the SDO model types. The only way to work around
this was for the user to supply (invalid) schemas without the
sdoModel.xsdimport.
The solution I have made was to make 2 changes to SDO XSDEcoreBuilder, one
to avoid any conversion when an import in the namespace commonj.sdo was
encountered ...
new override method on SDOXSDEcoreBuilder ...
public void generate(XSDSchema xsdSchema) {
// permits schemas to be valid by having an import of sdoModel.xsdwithout
// that import causing masking of the singleton instance of the
generated model
if(!ModelPackageImpl.eNS_URI.equals(xsdSchema.getTargetNamespace())) {
List contents = xsdSchema.getContents();
List commonjImports = new ArrayList();
for (Iterator i = contents.iterator(); i.hasNext(); )
{
Object content = i.next();
if (content instanceof XSDImport)
{
XSDImport xsdImport = (XSDImport)content;
if (ModelPackageImpl.eNS_URI.equals(xsdImport.getNamespace())) {
commonjImports.add(xsdImport);
}
}
}
contents.removeAll(commonjImports);
super.generate(xsdSchema);
}
}
and the other to do a special case on looking up classifiers when they are
in the commonj.sdo namespace
public EClassifier getEClassifier(XSDTypeDefinition xsdTypeDefinition) {
EClassifier eClassifier = null;
if (rootSchema.getSchemaForSchemaNamespace().equals(
xsdTypeDefinition.getTargetNamespace())) {
eClassifier =
getBuiltInEClassifier(
xsdTypeDefinition.getURI(),
xsdTypeDefinition.getName());
} else if (ModelPackageImpl.eNS_URI.equals(
xsdTypeDefinition.getTargetNamespace())) {
eClassifier = ModelPackageImpl.eINSTANCE.getEClassifier(
xsdTypeDefinition.getName());
} else {
eClassifier = super.getEClassifier(xsdTypeDefinition);
}
return eClassifier;
}
Regards, Kelvin.
On 14/09/06, Fuhwei Lwo <[EMAIL PROTECTED]> wrote:
I think we may have a scenario that Java SDO codegen would fail
to generate Java codes from XSD. The scenario is when I tried to
run codegen tool on sdoModel.xsd with target namespace, commonj.sdo,
the codegen would perform no-op. The reason is the fix for TUSCANY-676
has forced SDOXSDEcoreBuilder to load types of the commonj.sdo namespace
so when XSD2JavaGenerator.java invokes XSDHelper.define() method to
load sdoModel.xsd again for codegen, define() method won't register
commonj.sdo namespace because it already exists.
After looking into XSD2JavaGenerator.java, I think what it needs is
to have a clean/empty registry without any SDO types registered.
However, the current implementation is to use both EMF (for codegen APIs)
and SDO (for utilizing define() method) APIs but SDO didn't provide a
way of not registering its default model, sdoModel.xsd. If we go down
this road, we need to fix SDOXSDEcoreBuilder.java to create a
constructor without init sdoModel. However, this is not enough.
XSD2JavaGenerator needs to access extendedMetaData in XSDHelperImpl to get
to the registry so XSDHelperImpl needs to expose its private
member, extendedMetaData. I don't think this is a good idea.
Another alternative is to add a new argument to the
XSDHelperImpl constructor to indicate whether the default SDO model should
be init so XSD2JavaGenerator can create an instance of XSDHelperImpl
without initializing the SDO model.
Another alternative is XSD2JavaGenerator basically doesn't
use XSDHelper or other SDO APIs. Use EMF APIs instead. This approach
may duplicate some codes but we don't worry about bridging two sets of API.
Let me know what you think so I can prototype the solution. Thanks.
Fuhwei
