You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Brian Bonner <bk...@gmail.com> on 2005/12/01 15:45:44 UTC
Re: error in geronimo-connector-1.0.xsd
Is there a bugzilla for this issue out for th WTP folks? If it's
fixed in EMF 2.2, the WTP guys need to know that EMF 2.1 is broken.
Brian
On 11/30/05, Jeff Genender <jg...@apache.org> wrote:
> 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" <jg...@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 <sp...@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 <bk...@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 <bk...@gmail.com> wrote:
> >>>>>>>
> >>>>>>>> Sachin,
> >>>>>>>>
> >>>>>>>> I pulled the xsd from here: http://www.w3.org/2001/xml.xsd
> >>>>>>>>
> >>>>>>>> Brian
> >>>>>>>> On 11/30/05, Sachin Patel <sp...@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 <jg...@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 <me...@ca.ibm.com>
> >>>>>>>>>>>>> Organization: EclipseCorner
> >>>>>>>>>>>>> Newsgroups: eclipse.tools.emf
> >>>>>>>>>>>>> References: <dm...@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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >
>
Re: error in geronimo-connector-1.0.xsd
Posted by Sachin Patel <sp...@gmail.com>.
No not really. WTP will and should run on 2.2, The only issue is that a 2.2
generated model using the new schema will not run on a 2.1 runtime. So WTP
itself isn't affected since the J2EE models in WTP are based should be based
on the old schema. WTP 1.0 will be packaged with 2.1. If a user wants to
generate a model using the latest xsd schema, they simply need to bump up
their runtime once 2.2 is released.
On 12/1/05 9:45 AM, "Brian Bonner" <bk...@gmail.com> wrote:
> Is there a bugzilla for this issue out for th WTP folks? If it's
> fixed in EMF 2.2, the WTP guys need to know that EMF 2.1 is broken.
> Brian
> On 11/30/05, Jeff Genender <jg...@apache.org> wrote:
>> 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" <jg...@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 <sp...@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.des
>>>>>>>> cri
>>>>>>>> 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.des
>>>>>>>> cri
>>>>>>>> ptiontypeb480type)
>>>>>>>>
>>>>>>>> - code 13
>>>>>>>> at
>>>>>>>> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.readHand
>>>>>>>> le(
>>>>>>>> SchemaTypeSystemImpl.java:2000)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.readType
>>>>>>>> Ref
>>>>>>>> (SchemaTypeSystemImpl.java:2074)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.loadAttr
>>>>>>>> ibu
>>>>>>>> te(SchemaTypeSystemImpl.java:2891)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.readAttr
>>>>>>>> ibu
>>>>>>>> teData(SchemaTypeSystemImpl.java:2883)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl$XsbReader.finishLo
>>>>>>>> adi
>>>>>>>> ngType(SchemaTypeSystemImpl.java:2500)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.apache.xmlbeans.impl.schema.SchemaTypeSystemImpl.resolveHandle(Sche
>>>>>>>> maT
>>>>>>>> ypeSystemImpl.java:3476)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.apache.xmlbeans.SchemaComponent$Ref.getComponent(SchemaComponent.ja
>>>>>>>> va:
>>>>>>>> 104)
>>>>>>>>
>>>>>>>> at org.apache.xmlbeans.SchemaType$Ref.get(SchemaType.java:872)
>>>>>>>> at
>>>>>>>> org.apache.xmlbeans.impl.schema.SchemaParticleImpl.getType(SchemaPartic
>>>>>>>> leI
>>>>>>>> mpl.java:194)
>>>>>>>>
>>>>>>>> at
>>>>>>>>
>>> org.apache.xmlbeans.impl.validator.Validator.beginEvent(Validator.java:395>>
>>> >>>
>>> )
>>>>>>>> at
>>>>>>>> org.apache.xmlbeans.impl.validator.Validator.nextEvent(Validator.java:2
>>>>>>>> 47)
>>>>>>>>
>>>>>>>> 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.ja
>>>>>>>> va:
>>>>>>>> 346)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.apache.geronimo.schema.SchemaConversionUtils.validateDD(SchemaConve
>>>>>>>> rsi
>>>>>>>> onUtils.java:593)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.openejb.corba.security.config.tss.TSSConfigEditor.getValue(TSSConfi
>>>>>>>> gEd
>>>>>>>> itor.java:117)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.openejb.corba.security.config.tss.TSSConfigEditorTest.testSimple1(T
>>>>>>>> SSC
>>>>>>>> onfigEditorTest.java:104)
>>>>>>>>
>>>>>>>>
>>>>>>>> On 11/30/05, Brian Bonner <bk...@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 <bk...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Sachin,
>>>>>>>>>>
>>>>>>>>>> I pulled the xsd from here: http://www.w3.org/2001/xml.xsd
>>>>>>>>>>
>>>>>>>>>> Brian
>>>>>>>>>> On 11/30/05, Sachin Patel <sp...@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 <jg...@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 <me...@ca.ibm.com>
>>>>>>>>>>>> Organization: EclipseCorner
>>>>>>>>>>>> Newsgroups: eclipse.tools.emf
>>>>>>>>>>>> References: <dm...@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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>
>>