geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <jgenen...@apache.org>
Subject Re: error in geronimo-connector-1.0.xsd
Date Wed, 30 Nov 2005 22:05:19 GMT
My only concern with using the old is the 1998 schema says in the XSD:


    !!!THIS SCHEMA DOCUMENT IS OUT OF DATE!!!  It uses a preliminary W3C
    XML Schema syntax which has been superseded.
    The up-to-date version is at http://www.w3.org/2001/xml.xsd

So, unless there are major objections, I would stick with being up-to-date.

Jeff

Sachin Patel wrote:
> Kinda :) EMF 2.1 which is what WTP requires doesn't support the 2001 schema,
> but EMF 2.2 does.  So the import is still required for correctness, its just
> which version we want to go with.
> 
> Sachin
> 
> 
> On 11/30/05 4:52 PM, "Jeff Genender" <jgenender@apache.org> wrote:
> 
>> So it was eclipse ;-)
>>
>> Brian Bonner wrote:
>>> I'd say that we ought to support what is current and to have the
>>> eclipse guys get it fixed.
>> +1
>>
>> Jeff
>>
>>
>>> Brian
>>> On 11/30/05, Sachin Patel <sppatel2@gmail.com> wrote:
>>>> Shoot.  After changing the connector and security schema to point to the
>>>> 2001 version of xml.xsd, found a bug in EMF which Ed responded with:
>>>>
>>>> ...The XML namespace schema itself was changed. :-(   As a result, we
>>>> needed to regenerate that package to support the change changes.  That
>>>> work was done with:
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=110340  A workaround is to
>>>> redirect the schemaLocation for the xml.xsd to an older version.
>>>>
>>>> So, since we've been referencing the deprecated xml.xsd all this time
>>>> anyways with any concerns of moving up, would it be a huge issue if I
>>>> referenced back to that xsd instead of http://www.w3.org/2001/xml.xsd?
>>>> Sorry :)
>>>>
>>>> Sachin
>>>>
>>>> Sachin Patel wrote:
>>>>> Yes, you are correct.  Those two files which are in openejb need to be
>>>>> fixed as well, but since those are in a different repository someone
>>>>> else will need to fix them.
>>>>> Matt, David J, or David B, would you mind putting in the same import
>>>>> to resolve xml:lang for these two files?
>>>>>
>>>>> geronimo-service-1.0.xsd is a different issue.  The validation error
>>>>> is as described below...
>>>>>
>>>>> The namespace attribute
>>>>> 'http://geronimo.apache.org/xml/ns/deployment-1.0' of an <import>
>>>>> element information item must not be the same as the targetNamespace
>>>>> of the schema it exists in.    geronimo-service-1.0.xsd    a/schema
>>>>> line 35    November 30, 2005 2:56:01 PM    17
>>>>>
>>>>> As far as your error, I can't verify due to the itests not running at
>>>>> the moment.  Make your schemaLocation use the http://....xml.xsd, run
>>>>> clean at the root of open ejb, and rerun to ensure the new xmlbeans
>>>>> classes are being regenerated.
>>>>>
>>>>> Sachin
>>>>>
>>>>> Brian Bonner wrote:
>>>>>> I added:
>>>>>>
>>>>>>     <xsd:import namespace="http://www.w3.org/XML/1998/namespace"
>>>>>> schemaLocation="xml.xsd"/>
>>>>>>     <xsd:import
>>>>>> namespace="http://geronimo.apache.org/xml/ns/security-1.1"
>>>>>> schemaLocation="geronimo-security-1.1.xsd"/>
>>>>>>
>>>>>> to corba-tss-config-2.0.xsd
>>>>>>
>>>>>> but it's failing on:
>>>>>> Testsuite: org.openejb.corba.security.config.tss.TSSConfigEditorTest
>>>>>> Tests run: 4, Failures: 0, Errors: 1, Time elapsed: 1.75 sec
>>>>>>
>>>>>> Testcase:
>>>>>> testSimple1(org.openejb.corba.security.config.tss.TSSConfigEditorTest):
>>>>>> Caused
>>>>>> an ERROR
>>>>>> Cannot resolve type for handle
>>>>>> _XY_Q=lang|R=lang@http://www.w3.org/XML/1998/namespace
>>>>>> (schemaorg_apache_xmlbeans.system.sBCFA77F9E613DB031018700055C2136C.descri
>>>>>> ptiontypeb480type)
>>>>>>
>>>>>> - code 13
>>>>>> org.apache.xmlbeans.SchemaTypeLoaderException: Cannot resolve type
for
>>>>>> handle _XY_Q=lang|R=lang@http://www.w3.org/XML/1998/namespace
>>>>>> (schemaorg_apache_xmlbeans.system.sBCFA77F9E613DB031018700055C2136C.descri
>>>>>> ptiontypeb480type)
>>>>>>
>>>>>> - code 13
>>>>>>     at
>>>>>> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.readHandle(
>>>>>> SchemaTypeSystemImpl.java:2000)
>>>>>>
>>>>>>     at
>>>>>> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.readTypeRef
>>>>>> (SchemaTypeSystemImpl.java:2074)
>>>>>>
>>>>>>     at
>>>>>> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.loadAttribu
>>>>>> te(SchemaTypeSystemImpl.java:2891)
>>>>>>
>>>>>>     at
>>>>>> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.readAttribu
>>>>>> teData(SchemaTypeSystemImpl.java:2883)
>>>>>>
>>>>>>     at
>>>>>> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.finishLoadi
>>>>>> ngType(SchemaTypeSystemImpl.java:2500)
>>>>>>
>>>>>>     at
>>>>>> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.resolveHandle(SchemaT
>>>>>> ypeSystemImpl.java:3476)
>>>>>>
>>>>>>     at
>>>>>> org.apache.xmlbeans.SchemaComponent$Ref.getComponent(SchemaComponent.java:
>>>>>> 104)
>>>>>>
>>>>>>     at org.apache.xmlbeans.SchemaType$Ref.get(SchemaType.java:872)
>>>>>>     at
>>>>>> org.apache.xmlbeans.impl.schema.SchemaParticleImpl.getType(SchemaParticleI
>>>>>> mpl.java:194)
>>>>>>
>>>>>>     at
>>>>>>
> org.apache.xmlbeans.impl.validator.Validator.beginEvent(Validator.java:395>>>>>
> )
>>>>>>     at
>>>>>> org.apache.xmlbeans.impl.validator.Validator.nextEvent(Validator.java:247)
>>>>>>
>>>>>>     at
>>>>>> org.apache.xmlbeans.impl.store.Validate.emitEvent(Validate.java:172)
>>>>>>     at org.apache.xmlbeans.impl.store.Validate.process(Validate.java:79)
>>>>>>     at org.apache.xmlbeans.impl.store.Validate.<init>(Validate.java:39)
>>>>>>     at org.apache.xmlbeans.impl.store.Xobj.validate(Xobj.java:1780)
>>>>>>     at
>>>>>> org.apache.xmlbeans.impl.values.XmlObjectBase.validate(XmlObjectBase.java:
>>>>>> 346)
>>>>>>
>>>>>>     at
>>>>>> org.apache.geronimo.schema.SchemaConversionUtils.validateDD(SchemaConversi
>>>>>> onUtils.java:593)
>>>>>>
>>>>>>     at
>>>>>> org.openejb.corba.security.config.tss.TSSConfigEditor.getValue(TSSConfigEd
>>>>>> itor.java:117)
>>>>>>
>>>>>>     at
>>>>>> org.openejb.corba.security.config.tss.TSSConfigEditorTest.testSimple1(TSSC
>>>>>> onfigEditorTest.java:104)
>>>>>>
>>>>>>
>>>>>> On 11/30/05, Brian Bonner <bkbonner@gmail.com> wrote:
>>>>>>
>>>>>>> Jeff, Sachin,
>>>>>>>
>>>>>>> btw, I caught a problem in the corba stuff after the build:
>>>>>>>
>>>>>>> with:  corba-tss-config-2.0.xsd
>>>>>>>
>>>>>>> This has a similar import problem that I haven't yet resolved
which is
>>>>>>> causing my build to fail.
>>>>>>>
>>>>>>> geronimo-service-1.0.xsd  also has problems, but they're not
affecting
>>>>>>> me right now.
>>>>>>>
>>>>>>> Brian
>>>>>>>
>>>>>>>
>>>>>>> On 11/30/05, Brian Bonner <bkbonner@gmail.com> wrote:
>>>>>>>
>>>>>>>> Sachin,
>>>>>>>>
>>>>>>>> I pulled the xsd from here:  http://www.w3.org/2001/xml.xsd
>>>>>>>>
>>>>>>>> Brian
>>>>>>>> On 11/30/05, Sachin Patel <sppatel2@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> The patch is incorrect since it uses the deprecated xml.xsd,
I'm
>>>>>>>>> about
>>>>>>>>> to fix it using the correct schema location, verify xmlbeans
and emf
>>>>>>>>> code gen both work, and then commit.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Sachin.
>>>>>>>>>
>>>>>>>>> Brian Bonner wrote:
>>>>>>>>>
>>>>>>>>>> Jeff,
>>>>>>>>>>
>>>>>>>>>> I've fixed the patch I submitted at:
>>>>>>>>>> http://issues.apache.org/jira/browse/GERONIMO-1247
>>>>>>>>>>
>>>>>>>>>> I'm not sure which patch you refer to here, but I
built Geronimo
>>>>>>>>>> using
>>>>>>>>>> this patch which also fixes the schema issues and
makes xmlbeans
>>>>>>>>>> "happy".
>>>>>>>>>>
>>>>>>>>>> Maybe someone can test it in idea.  It seems to fix
issues in
>>>>>>>>>> Eclipse.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Brian
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/30/05, Jeff Genender <jgenender@apache.org>
wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Sachin Patel wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> I personally think this fix should go in,
not because a
>>>>>>>>>>>> particular IDE
>>>>>>>>>>>> or modeling tool does not tollerate it, but
because its
>>>>>>>>>>>> recommend as
>>>>>>>>>>>> best practice or required by specification.
 So if its true
>>>>>>>>>>>> that imports
>>>>>>>>>>>> aren't transitive, then the import should
be added.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> I have to agree with DJ on this one.  If its
us, then obviously
>>>>>>>>>>> we need
>>>>>>>>>>> to fix it.  If its eclipse, then they need to
fix it.  Based on
>>>>>>>>>>> your
>>>>>>>>>>> statement, do you have a copy of the blurb that
states the
>>>>>>>>>>> imports do
>>>>>>>>>>> not follow through from other imports?
>>>>>>>>>>>
>>>>>>>>>>> The fact it works in other IDEs and XMLBeans
parses it, leads me to
>>>>>>>>>>> believe its an Eclipse issue.  In fact running
a schema
>>>>>>>>>>> validation in
>>>>>>>>>>> Oxygen answers it as fully validated...and I
tend to believe
>>>>>>>>>>> Oxygen as
>>>>>>>>>>> they are one of the leaders in XML/XSD toolsets.
>>>>>>>>>>>
>>>>>>>>>>> However, I am more than happy to change my views
if this is truly a
>>>>>>>>>>> specification issue.
>>>>>>>>>>>
>>>>>>>>>>> Also, I tried that import in the security XSD,
and it does not
>>>>>>>>>>> seem to
>>>>>>>>>>> get rid of the error.
>>>>>>>>>>>
>>>>>>>>>>> If we do need to include the import, your patch
needs to be this:
>>>>>>>>>>>
>>>>>>>>>>> <xs:import namespace="http://www.w3.org/XML/1998/namespace"
>>>>>>>>>>> schemaLocation="http://www.w3.org/2001/xml.xsd">
>>>>>>>>>>>
>>>>>>>>>>> Your patch currently references a deprecated
xsd.
>>>>>>>>>>>
>>>>>>>>>>> Jeff
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Sachin
>>>>>>>>>>>>
>>>>>>>>>>>> David Jencks wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On Nov 29, 2005, at 12:43 PM, Jeff Genender
wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is XMLBeans able to work with it in its
current form?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, and I admit to ignoring this problem
since I tend to trust
>>>>>>>>>>>>> xmlbeans as the final arbiter of xml
schema compliance.  I
>>>>>>>>>>>>> think we
>>>>>>>>>>>>> might want to ask on the xmlbeans list
for their opinion.
>>>>>>>>>>>>> Right now I
>>>>>>>>>>>>> don't have the bandwidth for it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>  IntelliJ seems to accept it.  I am just
getting the error in
>>>>>>>>>>>>> Eclipse...this is why this concerns me
a little.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sachin Patel wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jeff,
>>>>>>>>>>>>> According to Ed, the schema isn't valid
without the import.
>>>>>>>>>>>>> See his
>>>>>>>>>>>>> response below.
>>>>>>>>>>>>> -------- Original Message --------
>>>>>>>>>>>>> Subject: Re: EMF can't resolve xml:lang
in schema
>>>>>>>>>>>>> Date: Tue, 29 Nov 2005 11:40:34 -0500
>>>>>>>>>>>>> From: Ed Merks <merks@ca.ibm.com>
>>>>>>>>>>>>> Organization: EclipseCorner
>>>>>>>>>>>>> Newsgroups: eclipse.tools.emf
>>>>>>>>>>>>> References: <dmhpt3$2i8$1@news.eclipse.org>
>>>>>>>>>>>>> Sachin,
>>>>>>>>>>>>> Imports in XML Schema are not transitive.
 I.e., importing a
>>>>>>>>>>>>> schema
>>>>>>>>>>>>> that
>>>>>>>>>>>>> in turn contains imports doesn't mean
you have indirectly
>>>>>>>>>>>>> imported all
>>>>>>>>>>>>> those too.  So if you use xml:lang in
your schema, your
>>>>>>>>>>>>> schema must
>>>>>>>>>>>>> contain an import for that.  Without
that import, your
>>>>>>>>>>>>> schema isn't
>>>>>>>>>>>>> valid.
>>>>>>>>>>>>> Jeff Genender wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't think you want to import this...the
1998 schema is
>>>>>>>>>>>>> supposed
>>>>>>>>>>>>> to be redirected to the 2001 version.
 It should already be
>>>>>>>>>>>>> imported from the reference to
>>>>>>>>>>>>> http://www.w3.org/2001/XMLSchema at
>>>>>>>>>>>>> he top.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Are you having problems building from
the command liine or
>>>>>>>>>>>>> from
>>>>>>>>>>>>> within Eclipse.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Apparently there seems to be an issue
in Eclipse with the
>>>>>>>>>>>>> subversion plugin that causes.  I have
not looked heavily
>>>>>>>>>>>>> into this
>>>>>>>>>>>>> issue...it can be found here:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://www.eclipse.org/newsportal/article.php?id=1390&group=eclipse
>>>>>>>>>>>>> .technology.xsd
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jeff
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sachin Patel wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes, I see this validation error as well.
There is a
>>>>>>>>>>>>> similar error
>>>>>>>>>>>>> also with geronimo-security-1.0.xsd.
 There is already an
>>>>>>>>>>>>> existing
>>>>>>>>>>>>> jira opened for this.  In the tools,
this problem prevents
>>>>>>>>>>>>> EMF
>>>>>>>>>>>>> code generation from completing and as
a workaround I
>>>>>>>>>>>>> patch the
>>>>>>>>>>>>> schema prior to codegen by including
the following import for
>>>>>>>>>>>>> geronimo-connector-1.0.xsd.
>>>>>>>>>>>>>
>>>>>>>>>>>>> <xs:import namespace="http://www.w3.org/XML/1998/namespace"
>>>>>>>>>>>>> schemaLocation="xml.xsd"/>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Brian Bonner wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm getting an error in the geronimo-connector-1.0.xsd,
>>>>>>>>>>>>> but I'm not
>>>>>>>>>>>>> sure if it's because of Eclipse's WTP
or something else.
>>>>>>>>>>>>>
>>>>>>>>>>>>> here's the error:
>>>>>>>>>>>>>
>>>>>>>>>>>>> src-resolve.4.2: Error resolving component
'xml:lang'. It
>>>>>>>>>>>>> was
>>>>>>>>>>>>> detected
>>>>>>>>>>>>> that 'xml:lang' is in namespace
>>>>>>>>>>>>> 'http://www.w3.org/XML/1998/namespace',
but components
>>>>>>>>>>>>> from this
>>>>>>>>>>>>> namespace are not referenceable from
schema document
>>>>>>>>>>>>> 'file:///C:/workspace_paraware/testschema/schema/geronimo-connector
>>>>>>>>>>>>> -1.0.xsd'.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> If this is the incorrect namespace, perhaps
the prefix of
>>>>>>>>>>>>> 'xml:lang'
>>>>>>>>>>>>> needs to be changed. If this is the correct
namespace,
>>>>>>>>>>>>> then an
>>>>>>>>>>>>> appropriate 'import' tag should be added
to
>>>>>>>>>>>>> 'file:///C:/workspace_paraware/testschema/schema/geronimo-connector
>>>>>>>>>>>>> -1.0.xsd'.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> it's occurring in line 391:
>>>>>>>>>>>>>
>>>>>>>>>>>>>     <xs:complexType name="descriptionType">
>>>>>>>>>>>>>         <xs:simpleContent>
>>>>>>>>>>>>>             <xs:extension base="xs:string">
>>>>>>>>>>>>>                 <xs:attribute ref="xml:lang"/>
 <!--
>>>>>>>>>>>>> right here
>>>>>>>>>>>>> -->
>>>>>>>>>>>>>             </xs:extension>
>>>>>>>>>>>>>         </xs:simpleContent>
>>>>>>>>>>>>>     </xs:complexType>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is anyone else seeing this?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Brian
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
> 

Mime
View raw message