Menu
▾
▴
openoss-devel
|
From: Craig G. (opennms) <cg...@op...> - 2012-05-31 21:57:52
Attachments:
dep_cbe_perf_spec.xsd
|
Hi, I have been testing the TIP_PM_Col project model and have found that the dep_cbe_perf_spec.xsd (attached) file is generated with errors in line 62 we have <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" minOccurs="0" maxOccurs="1"> filter:XPathQueryFilter is not defined and if you open the file in eclipse it reports this error as: 's4s-att-invalid-value: Invalid attribute value for 'type' in element 'element'. Recorded reason: UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: the prefix 'filter' is not declared'. Is this a known problem or a new bug? Craig |
|
From: Flauw, M. <Mar...@hp...> - 2012-06-01 09:28:41
|
Craig, There is one same filter in the getReosurceAlarms operation, filter argument. The XPathFilter is defined in the internal_filter.xsd Best regards Marc -----Original Message----- From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms) Sent: Thursday, May 31, 2012 11:58 PM To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier Subject: Problems with PM XSD generation Hi, I have been testing the TIP_PM_Col project model and have found that the dep_cbe_perf_spec.xsd (attached) file is generated with errors in line 62 we have <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" minOccurs="0" maxOccurs="1"> filter:XPathQueryFilter is not defined and if you open the file in eclipse it reports this error as: 's4s-att-invalid-value: Invalid attribute value for 'type' in element 'element'. Recorded reason: UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: the prefix 'filter' is not declared'. Is this a known problem or a new bug? Craig |
|
From: Xose R. S. V. <xr...@op...> - 2012-06-01 12:00:11
|
I am going to view the problem to see which is the cause Regards El 31/05/2012 23:57, Craig Gallen (opennms) escribió: > Hi, > > I have been testing the TIP_PM_Col project model and have found that > the dep_cbe_perf_spec.xsd (attached) file is generated with errors > > in line 62 we have > <xsd:element name="objectInstanceFilter" > type="filter:XPathQueryFilter" minOccurs="0" maxOccurs="1"> > > filter:XPathQueryFilter is not defined and if you open the file in > eclipse it reports this error as: > > 's4s-att-invalid-value: Invalid attribute value for 'type' in element > 'element'. Recorded reason: > UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a > QName: the prefix 'filter' is not > declared'. > > Is this a known problem or a new bug? > > Craig -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Xose R. S. V. <xr...@op...> - 2012-06-11 11:42:54
|
Hi all. I think that I have found the error and I will try to fix it as
soon as possible. There are some related issues, one error in the
codification of a method and a forgetted evaluation of filtering in the
velocity template and also a case related with primitive type filter not
supported in the build of the closure outside the interfaces.
In the interfaces build the search is performed as follows(this works
fine as reported Marc):
if ("objectName".equalsIgnoreCase(argType.getName())) {
/*
* This data type 'objectName' defines the
protocol
* neutral unique name of an object. This
data type will
* be replaced by the generators by an
EntityIdentifier
*/
String pkg = PluginConstants
.getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG);
if (!this.map.containsKey(pkg)) {
//
// New package - add new pkg=prefix mapping
// assignment
//
String prefix =
XmlSchemaHelpers.generateXmlPrefix(
pkg, this.map);
this.map.put(pkg, prefix);
}
} else if
("filter".equalsIgnoreCase(argType.getName())) {
/*
* This data type 'filter'. This data type will
* be replaced by the generator to
*/
String pkg = PluginConstants
.getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG);
if (!this.map.containsKey(pkg)) {
//
// New package - add new pkg=prefix mapping
// assignment
//
String prefix =
XmlSchemaHelpers.generateXmlPrefix(
pkg, this.map);
this.map.put(pkg, prefix);
}
} else if (XmlSchemaHelpers.isUnbounded(argType)) {
String pkg = PluginConstants
.getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG);
if (!this.map.containsKey(pkg)) {
//
// New package - add new pkg=prefix mapping
// assignment
//
String prefix =
XmlSchemaHelpers.generateXmlPrefix(
pkg, this.map);
this.map.put(pkg, prefix);
}
} else {
// XSD default namespace is enough
}
and in the build of the closure we have got (this fails as reported Craig):
if ("objectName".equalsIgnoreCase(type.getName())){
PluginLog.logDebug("type \'" + type
+ "\' is an array of primitive.");
addReferencedPackage(PluginConstants
.getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG));
}else if (XmlSchemaHelpers.isUnbounded(type)){
//will map to array of primitive
addReferencedPackage(PluginConstants
.getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG));
} else {
//normal primtive like xsd:int
}
so the filtering never is considered.
I will perform clean tests because was very difficult to find the real
cause of the problem, the log file is not very clear in debug scenarios
( a lot of similar log text, no log from the templates and also cannot
put the line number in the log file (tigerstripe issue)) and these
problems have delayed my response.
If the test go ok I will check out the changes to the trunk
https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator
Best regards
El 01/06/2012 16:58, Craig Gallen escribió:
> Hi,
>
> I agree it is defined in internal_filter.xsd but it doesn't seem to be
> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java
> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also
> shows an error.
>
> I think Xose is looking into it
>
> Craig
>
> -----Original Message-----
> From: Flauw, Marc [mailto:Mar...@hp...]
> Sent: 01 June 2012 10:25
> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre
> gauthier
> Subject: RE: Problems with PM XSD generation
>
> Craig,
>
> There is one same filter in the getReosurceAlarms operation, filter
> argument.
> The XPathFilter is defined in the internal_filter.xsd
>
> Best regards
>
> Marc
>
> -----Original Message-----
> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig
> Gallen (opennms)
> Sent: Thursday, May 31, 2012 11:58 PM
> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier
> Subject: Problems with PM XSD generation
>
> Hi,
>
> I have been testing the TIP_PM_Col project model and have found that the
> dep_cbe_perf_spec.xsd (attached) file is generated with errors
>
> in line 62 we have
> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter"
> minOccurs="0" maxOccurs="1">
>
> filter:XPathQueryFilter is not defined and if you open the file in eclipse
> it reports this error as:
>
> 's4s-att-invalid-value: Invalid attribute value for 'type' in element
> 'element'. Recorded reason:
> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName:
> the prefix 'filter' is not
> declared'.
>
> Is this a known problem or a new bug?
>
> Craig
>
--
*Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D
T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029
www.optaresolutions.com
<http://www.optaresolutions.com>
Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com>
|
|
From: Xose R. S. V. <xr...@op...> - 2012-06-11 14:12:32
|
I've performed the checkin in the TRUNK for the *Soap Generator *and
the*Soap Generator Packag*e to support for internal filter in creation
of closure as in service interface
Best regards
El 11/06/2012 13:35, Xose Ramon Sousa Vazquez escribió:
> Hi all. I think that I have found the error and I will try to fix it
> as soon as possible. There are some related issues, one error in the
> codification of a method and a forgetted evaluation of filtering in
> the velocity template and also a case related with primitive type
> filter not supported in the build of the closure outside the interfaces.
>
> In the interfaces build the search is performed as follows(this works
> fine as reported Marc):
>
> if ("objectName".equalsIgnoreCase(argType.getName())) {
> /*
> * This data type 'objectName' defines the
> protocol
> * neutral unique name of an object. This
> data type will
> * be replaced by the generators by an
> EntityIdentifier
> */
> String pkg = PluginConstants
>
> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG);
> if (!this.map.containsKey(pkg)) {
> //
> // New package - add new pkg=prefix
> mapping
> // assignment
> //
> String prefix =
> XmlSchemaHelpers.generateXmlPrefix(
> pkg, this.map);
> this.map.put(pkg, prefix);
> }
> } else if
> ("filter".equalsIgnoreCase(argType.getName())) {
> /*
> * This data type 'filter'. This data type
> will
> * be replaced by the generator to
> */
> String pkg = PluginConstants
>
> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG);
> if (!this.map.containsKey(pkg)) {
> //
> // New package - add new pkg=prefix
> mapping
> // assignment
> //
> String prefix =
> XmlSchemaHelpers.generateXmlPrefix(
> pkg, this.map);
> this.map.put(pkg, prefix);
> }
> } else if
> (XmlSchemaHelpers.isUnbounded(argType)) {
> String pkg = PluginConstants
>
> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG);
> if (!this.map.containsKey(pkg)) {
> //
> // New package - add new pkg=prefix
> mapping
> // assignment
> //
> String prefix =
> XmlSchemaHelpers.generateXmlPrefix(
> pkg, this.map);
> this.map.put(pkg, prefix);
> }
> } else {
> // XSD default namespace is enough
> }
>
> and in the build of the closure we have got (this fails as reported
> Craig):
>
> if ("objectName".equalsIgnoreCase(type.getName())){
> PluginLog.logDebug("type \'" + type
> + "\' is an array of primitive.");
> addReferencedPackage(PluginConstants
>
> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG));
> }else if (XmlSchemaHelpers.isUnbounded(type)){
> //will map to array of primitive
> addReferencedPackage(PluginConstants
>
> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG));
> } else {
> //normal primtive like xsd:int
> }
>
> so the filtering never is considered.
>
> I will perform clean tests because was very difficult to find the real
> cause of the problem, the log file is not very clear in debug
> scenarios ( a lot of similar log text, no log from the templates and
> also cannot put the line number in the log file (tigerstripe issue))
> and these problems have delayed my response.
> If the test go ok I will check out the changes to the trunk
>
> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator
>
> Best regards
>
>
> El 01/06/2012 16:58, Craig Gallen escribió:
>> Hi,
>>
>> I agree it is defined in internal_filter.xsd but it doesn't seem to be
>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java
>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also
>> shows an error.
>>
>> I think Xose is looking into it
>>
>> Craig
>>
>> -----Original Message-----
>> From: Flauw, Marc [mailto:Mar...@hp...]
>> Sent: 01 June 2012 10:25
>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre
>> gauthier
>> Subject: RE: Problems with PM XSD generation
>>
>> Craig,
>>
>> There is one same filter in the getReosurceAlarms operation, filter
>> argument.
>> The XPathFilter is defined in the internal_filter.xsd
>>
>> Best regards
>>
>> Marc
>>
>> -----Original Message-----
>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig
>> Gallen (opennms)
>> Sent: Thursday, May 31, 2012 11:58 PM
>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier
>> Subject: Problems with PM XSD generation
>>
>> Hi,
>>
>> I have been testing the TIP_PM_Col project model and have found that the
>> dep_cbe_perf_spec.xsd (attached) file is generated with errors
>>
>> in line 62 we have
>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter"
>> minOccurs="0" maxOccurs="1">
>>
>> filter:XPathQueryFilter is not defined and if you open the file in eclipse
>> it reports this error as:
>>
>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element
>> 'element'. Recorded reason:
>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName:
>> the prefix 'filter' is not
>> declared'.
>>
>> Is this a known problem or a new bug?
>>
>> Craig
>>
>
>
> --
>
> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D
> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029
> www.optaresolutions.com
> <http://www.optaresolutions.com>
> Optare Solutions
> <http://optarecoolvendor.com><http://optarecoolvendor.com>
>
--
*Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D
T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029
www.optaresolutions.com
<http://www.optaresolutions.com>
Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com>
|
|
From: Xose R. S. V. <xr...@op...> - 2012-06-25 15:03:50
|
Hi Craig, when you talk about the updated Soap Plugin, which version (in
svn url) are using?, because the two first issues seems to be solved in
the trunk with the other Tigerstripe version.
Regards
El 25/06/2012 16:54, Craig Gallen (entimoss) escribió:
> Hi Xose,
>
> I just updated my tigerstripe to the latest release 0.7.0.20120618258
> but Ialso updated the Soap plug-in and have found multiple problems
> but I am not sure if they are all related to the tigerstripe upgrade
> or to the current state of the soap plugin. Could you build the RAM
> project and check the generated XSD's to see the problem.
>
> 1. when you build the RAM project there is a problem with model
> closure. None of the Dependency XSD's get generated in the RAM_Model
> project
>
> 2. TrackingRecordResultWithIterator referenced as
> 'problem:TrackingRecordResultWithIterator' in
> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd is
> never generated.
>
> 3. Tigerstripe 0.7.0.20120618258. handles primitive.string differently
> and generates type 'String' instead of 'java.lang.String' this results
> in type :String instead of xsd:string. I did a quick fix given in the
> following patch adding
> || "String".equalsIgnoreCase(refType.getFullyQualifiedName()))
>
> to
> || "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName())
> this means that old and new versions of tigerstipe will work
>
> There is a patch below but havent checked this in because I was not
> sure that else you were doing to the Soap plugin
>
> Craig
>
>
>
> ### Eclipse Workspace Patch 1.0
> #P TIP_Soap_Generator
> Index:
> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java
> ===================================================================
> ---
> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java
> (revision 3453)
> +++
> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java
> (working copy)
> @@ -510,8 +510,8 @@
> */
> if (refType.isPrimitive()
> || refType.getPackage().equalsIgnoreCase("primitive")
> - || "java.lang.String".equalsIgnoreCase(refType
> - .getFullyQualifiedName())) {
> + ||
> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName())
> + ||
> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { //
> tigerstripe 1.7.0 now generates String and not java.lang.String
> PluginLog.logDebug("\'" + refTypeFullName
> + "\' is a primitive type in current TIP profile.");
> type = mapPrimitivesToXsdType(refType.getName(),
> isArray(refType),
> @@ -519,7 +519,7 @@
> }
>
> /**
> - * Map datatyeps and enumerations
> + * Map datatypes and enumerations
> */
> // if (refType.isDatatype() || refType.isEnum()
> else if (isDatatype(refType) || isEnumeration(refType)) {
> Index:
> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java
> ===================================================================
> ---
> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java
> (revision 3453)
> +++
> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java
> (working copy)
> @@ -170,8 +170,9 @@
> private void addReferencedPackage(IType type) {
>
> if (type.isPrimitive()
> - || "primitive".equalsIgnoreCase(type.getPackage()) ||
> -
> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) {
> + || "primitive".equalsIgnoreCase(type.getPackage())
> + ||
> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())
> + ||
> "String".equalsIgnoreCase(type.getFullyQualifiedName())) { //
> tigerstripe 1.7.0 now generates String and not java.lang.String
> //will map objectName to EntityIdentifier or
> ArrayOfEntityIdentifier
> if ("objectName".equalsIgnoreCase(type.getName())){
> PluginLog.logDebug("type \'" + type
> @@ -378,8 +379,8 @@
> */
> if (refType.isPrimitive()
> || refType.getPackage().equalsIgnoreCase("primitive")
> - || "java.lang.String".equalsIgnoreCase(refType
> - .getFullyQualifiedName())) {
> + ||
> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName())
> + ||
> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { //
> tigerstripe 1.7.0 now generates String and not java.lang.String
> PluginLog.logDebug("\'" + typeName
> + "\' is a primitive type in current TIP profile.");
>
>
>
>
>
>
>
> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote:
>> Hi all. I think that I have found the error and I will try to fix it
>> as soon as possible. There are some related issues, one error in the
>> codification of a method and a forgetted evaluation of filtering in
>> the velocity template and also a case related with primitive type
>> filter not supported in the build of the closure outside the interfaces.
>>
>> In the interfaces build the search is performed as follows(this works
>> fine as reported Marc):
>>
>> if ("objectName".equalsIgnoreCase(argType.getName())) {
>> /*
>> * This data type 'objectName' defines
>> the protocol
>> * neutral unique name of an object. This
>> data type will
>> * be replaced by the generators by an
>> EntityIdentifier
>> */
>> String pkg = PluginConstants
>>
>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG);
>> if (!this.map.containsKey(pkg)) {
>> //
>> // New package - add new pkg=prefix
>> mapping
>> // assignment
>> //
>> String prefix =
>> XmlSchemaHelpers.generateXmlPrefix(
>> pkg, this.map);
>> this.map.put(pkg, prefix);
>> }
>> } else if
>> ("filter".equalsIgnoreCase(argType.getName())) {
>> /*
>> * This data type 'filter'. This data
>> type will
>> * be replaced by the generator to
>> */
>> String pkg = PluginConstants
>>
>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG);
>> if (!this.map.containsKey(pkg)) {
>> //
>> // New package - add new pkg=prefix
>> mapping
>> // assignment
>> //
>> String prefix =
>> XmlSchemaHelpers.generateXmlPrefix(
>> pkg, this.map);
>> this.map.put(pkg, prefix);
>> }
>> } else if
>> (XmlSchemaHelpers.isUnbounded(argType)) {
>> String pkg = PluginConstants
>>
>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG);
>> if (!this.map.containsKey(pkg)) {
>> //
>> // New package - add new pkg=prefix
>> mapping
>> // assignment
>> //
>> String prefix =
>> XmlSchemaHelpers.generateXmlPrefix(
>> pkg, this.map);
>> this.map.put(pkg, prefix);
>> }
>> } else {
>> // XSD default namespace is enough
>> }
>>
>> and in the build of the closure we have got (this fails as reported
>> Craig):
>>
>> if ("objectName".equalsIgnoreCase(type.getName())){
>> PluginLog.logDebug("type \'" + type
>> + "\' is an array of primitive.");
>> addReferencedPackage(PluginConstants
>>
>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG));
>> }else if (XmlSchemaHelpers.isUnbounded(type)){
>> //will map to array of primitive
>> addReferencedPackage(PluginConstants
>>
>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG));
>> } else {
>> //normal primtive like xsd:int
>> }
>>
>> so the filtering never is considered.
>>
>> I will perform clean tests because was very difficult to find the
>> real cause of the problem, the log file is not very clear in debug
>> scenarios ( a lot of similar log text, no log from the templates and
>> also cannot put the line number in the log file (tigerstripe issue))
>> and these problems have delayed my response.
>> If the test go ok I will check out the changes to the trunk
>>
>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator
>>
>> Best regards
>>
>>
>> El 01/06/2012 16:58, Craig Gallen escribió:
>>> Hi,
>>>
>>> I agree it is defined in internal_filter.xsd but it doesn't seem to be
>>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java
>>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also
>>> shows an error.
>>>
>>> I think Xose is looking into it
>>>
>>> Craig
>>>
>>> -----Original Message-----
>>> From: Flauw, Marc [mailto:Mar...@hp...]
>>> Sent: 01 June 2012 10:25
>>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre
>>> gauthier
>>> Subject: RE: Problems with PM XSD generation
>>>
>>> Craig,
>>>
>>> There is one same filter in the getReosurceAlarms operation, filter
>>> argument.
>>> The XPathFilter is defined in the internal_filter.xsd
>>>
>>> Best regards
>>>
>>> Marc
>>>
>>> -----Original Message-----
>>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig
>>> Gallen (opennms)
>>> Sent: Thursday, May 31, 2012 11:58 PM
>>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier
>>> Subject: Problems with PM XSD generation
>>>
>>> Hi,
>>>
>>> I have been testing the TIP_PM_Col project model and have found that the
>>> dep_cbe_perf_spec.xsd (attached) file is generated with errors
>>>
>>> in line 62 we have
>>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter"
>>> minOccurs="0" maxOccurs="1">
>>>
>>> filter:XPathQueryFilter is not defined and if you open the file in eclipse
>>> it reports this error as:
>>>
>>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element
>>> 'element'. Recorded reason:
>>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName:
>>> the prefix 'filter' is not
>>> declared'.
>>>
>>> Is this a known problem or a new bug?
>>>
>>> Craig
>>>
>>
>>
>> --
>>
>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D
>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029
>> www.optaresolutions.com
>> <http://www.optaresolutions.com>
>> Optare Solutions
>> <http://optarecoolvendor.com><http://optarecoolvendor.com>
>>
--
*Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D
T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029
www.optaresolutions.com
<http://www.optaresolutions.com>
Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com>
|
|
From: Craig G. (opennms) <cg...@op...> - 2012-06-25 15:51:47
|
-------- Original Message --------
Subject: Re: Problems with PM XSD generation
Date: Mon, 25 Jun 2012 15:54:32 +0100
From: Craig Gallen (entimoss) <cra...@en...>
Organisation: Entmoss Ltd
To: Xose Ramon Sousa Vazquez <xr...@op...>
CC: 'Flauw, Marc' <Mar...@hp...>, 'Craig Gallen (opennms)'
<cg...@op...>, 'openoss-devel'
<ope...@li...>, 'pierre gauthier'
<pie...@os...>
Hi Xose,
I just updated my tigerstripe to the latest release 0.7.0.20120618258
but Ialso updated the Soap plug-in and have found multiple problems but
I am not sure if they are all related to the tigerstripe upgrade or to
the current state of the soap plugin. Could you build the RAM project
and check the generated XSD's to see the problem.
1. when you build the RAM project there is a problem with model
closure. None of the Dependency XSD's get generated in the RAM_Model
project
2. TrackingRecordResultWithIterator referenced as
'problem:TrackingRecordResultWithIterator' in
ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd is
never generated.
3. Tigerstripe 0.7.0.20120618258. handles primitive.string differently
and generates type 'String' instead of 'java.lang.String' this results
in type :String instead of xsd:string. I did a quick fix given in the
following patch adding
|| "String".equalsIgnoreCase(refType.getFullyQualifiedName()))
to
|| "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName())
this means that old and new versions of tigerstipe will work
There is a patch below but havent checked this in because I was not
sure that else you were doing to the Soap plugin
Craig
### Eclipse Workspace Patch 1.0
#P TIP_Soap_Generator
Index:
src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java
===================================================================
---
src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java
(revision 3453)
+++
src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java
(working copy)
@@ -510,8 +510,8 @@
*/
if (refType.isPrimitive()
|| refType.getPackage().equalsIgnoreCase("primitive")
- || "java.lang.String".equalsIgnoreCase(refType
- .getFullyQualifiedName())) {
+ ||
"java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName())
+ ||
"String".equalsIgnoreCase(refType.getFullyQualifiedName())) { //
tigerstripe 1.7.0 now generates String and not java.lang.String
PluginLog.logDebug("\'" + refTypeFullName
+ "\' is a primitive type in current TIP profile.");
type = mapPrimitivesToXsdType(refType.getName(),
isArray(refType),
@@ -519,7 +519,7 @@
}
/**
- * Map datatyeps and enumerations
+ * Map datatypes and enumerations
*/
// if (refType.isDatatype() || refType.isEnum()
else if (isDatatype(refType) || isEnumeration(refType)) {
Index:
src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java
===================================================================
---
src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java
(revision 3453)
+++
src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java
(working copy)
@@ -170,8 +170,9 @@
private void addReferencedPackage(IType type) {
if (type.isPrimitive()
- || "primitive".equalsIgnoreCase(type.getPackage()) ||
-
"java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) {
+ || "primitive".equalsIgnoreCase(type.getPackage())
+ ||
"java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())
+ ||
"String".equalsIgnoreCase(type.getFullyQualifiedName())) { //
tigerstripe 1.7.0 now generates String and not java.lang.String
//will map objectName to EntityIdentifier or
ArrayOfEntityIdentifier
if ("objectName".equalsIgnoreCase(type.getName())){
PluginLog.logDebug("type \'" + type
@@ -378,8 +379,8 @@
*/
if (refType.isPrimitive()
|| refType.getPackage().equalsIgnoreCase("primitive")
- || "java.lang.String".equalsIgnoreCase(refType
- .getFullyQualifiedName())) {
+ ||
"java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName())
+ ||
"String".equalsIgnoreCase(refType.getFullyQualifiedName())) { //
tigerstripe 1.7.0 now generates String and not java.lang.String
PluginLog.logDebug("\'" + typeName
+ "\' is a primitive type in current TIP profile.");
On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote:
> Hi all. I think that I have found the error and I will try to fix it
> as soon as possible. There are some related issues, one error in the
> codification of a method and a forgetted evaluation of filtering in
> the velocity template and also a case related with primitive type
> filter not supported in the build of the closure outside the interfaces.
>
> In the interfaces build the search is performed as follows(this works
> fine as reported Marc):
>
> if ("objectName".equalsIgnoreCase(argType.getName())) {
> /*
> * This data type 'objectName' defines the
> protocol
> * neutral unique name of an object. This
> data type will
> * be replaced by the generators by an
> EntityIdentifier
> */
> String pkg = PluginConstants
>
> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG);
> if (!this.map.containsKey(pkg)) {
> //
> // New package - add new pkg=prefix
> mapping
> // assignment
> //
> String prefix =
> XmlSchemaHelpers.generateXmlPrefix(
> pkg, this.map);
> this.map.put(pkg, prefix);
> }
> } else if
> ("filter".equalsIgnoreCase(argType.getName())) {
> /*
> * This data type 'filter'. This data type
> will
> * be replaced by the generator to
> */
> String pkg = PluginConstants
>
> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG);
> if (!this.map.containsKey(pkg)) {
> //
> // New package - add new pkg=prefix
> mapping
> // assignment
> //
> String prefix =
> XmlSchemaHelpers.generateXmlPrefix(
> pkg, this.map);
> this.map.put(pkg, prefix);
> }
> } else if
> (XmlSchemaHelpers.isUnbounded(argType)) {
> String pkg = PluginConstants
>
> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG);
> if (!this.map.containsKey(pkg)) {
> //
> // New package - add new pkg=prefix
> mapping
> // assignment
> //
> String prefix =
> XmlSchemaHelpers.generateXmlPrefix(
> pkg, this.map);
> this.map.put(pkg, prefix);
> }
> } else {
> // XSD default namespace is enough
> }
>
> and in the build of the closure we have got (this fails as reported
> Craig):
>
> if ("objectName".equalsIgnoreCase(type.getName())){
> PluginLog.logDebug("type \'" + type
> + "\' is an array of primitive.");
> addReferencedPackage(PluginConstants
>
> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG));
> }else if (XmlSchemaHelpers.isUnbounded(type)){
> //will map to array of primitive
> addReferencedPackage(PluginConstants
>
> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG));
> } else {
> //normal primtive like xsd:int
> }
>
> so the filtering never is considered.
>
> I will perform clean tests because was very difficult to find the real
> cause of the problem, the log file is not very clear in debug
> scenarios ( a lot of similar log text, no log from the templates and
> also cannot put the line number in the log file (tigerstripe issue))
> and these problems have delayed my response.
> If the test go ok I will check out the changes to the trunk
>
> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator
>
> Best regards
>
>
> El 01/06/2012 16:58, Craig Gallen escribió:
>> Hi,
>>
>> I agree it is defined in internal_filter.xsd but it doesn't seem to be
>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java
>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also
>> shows an error.
>>
>> I think Xose is looking into it
>>
>> Craig
>>
>> -----Original Message-----
>> From: Flauw, Marc [mailto:Mar...@hp...]
>> Sent: 01 June 2012 10:25
>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre
>> gauthier
>> Subject: RE: Problems with PM XSD generation
>>
>> Craig,
>>
>> There is one same filter in the getReosurceAlarms operation, filter
>> argument.
>> The XPathFilter is defined in the internal_filter.xsd
>>
>> Best regards
>>
>> Marc
>>
>> -----Original Message-----
>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig
>> Gallen (opennms)
>> Sent: Thursday, May 31, 2012 11:58 PM
>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier
>> Subject: Problems with PM XSD generation
>>
>> Hi,
>>
>> I have been testing the TIP_PM_Col project model and have found that the
>> dep_cbe_perf_spec.xsd (attached) file is generated with errors
>>
>> in line 62 we have
>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter"
>> minOccurs="0" maxOccurs="1">
>>
>> filter:XPathQueryFilter is not defined and if you open the file in eclipse
>> it reports this error as:
>>
>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element
>> 'element'. Recorded reason:
>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName:
>> the prefix 'filter' is not
>> declared'.
>>
>> Is this a known problem or a new bug?
>>
>> Craig
>>
>
>
> --
>
> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D
> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029
> www.optaresolutions.com
> <http://www.optaresolutions.com>
> Optare Solutions
> <http://optarecoolvendor.com><http://optarecoolvendor.com>
>
|
|
From: Craig G. (opennms) <cg...@op...> - 2012-06-25 16:39:19
|
Hi
Great. Update to latest JVT plugin in trunk and JVT should work with String.
Thanks,
Craig
On 25/06/2012 17:03, Flauw, Marc wrote:
>
> Craig,
>
> I managed to build RAM kit but it failed in JVT spec with String.
>
> I have Tigerstripe I50 with generators from 2 weeks ago and common
> model with job and schedule
>
> Best regards
>
> Marc
>
> *From:*Craig Gallen [mailto:gal...@go...] *On Behalf Of
> *Craig Gallen (entimoss)
> *Sent:* Monday, June 25, 2012 4:55 PM
> *To:* Xose Ramon Sousa Vazquez
> *Cc:* Flauw, Marc; 'Craig Gallen (opennms)'; 'openoss-devel'; 'pierre
> gauthier'
> *Subject:* Re: Problems with PM XSD generation
>
> Hi Xose,
>
> I just updated my tigerstripe to the latest release 0.7.0.20120618258
> but Ialso updated the Soap plug-in and have found multiple problems
> but I am not sure if they are all related to the tigerstripe upgrade
> or to the current state of the soap plugin. Could you build the RAM
> project and check the generated XSD's to see the problem.
>
> 1. when you build the RAM project there is a problem with model
> closure. None of the Dependency XSD's get generated in the RAM_Model
> project
>
> 2. TrackingRecordResultWithIterator referenced as
> 'problem:TrackingRecordResultWithIterator' in
> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd is
> never generated.
>
> 3. Tigerstripe 0.7.0.20120618258. handles primitive.string differently
> and generates type 'String' instead of 'java.lang.String' this results
> in type :String instead of xsd:string. I did a quick fix given in the
> following patch adding
> || "String".equalsIgnoreCase(refType.getFullyQualifiedName()))
>
> to
> || "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName())
> this means that old and new versions of tigerstipe will work
>
> There is a patch below but havent checked this in because I was not
> sure that else you were doing to the Soap plugin
>
> Craig
>
>
>
> ### Eclipse Workspace Patch 1.0
> #P TIP_Soap_Generator
> Index:
> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java
> ===================================================================
> ---
> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java
> (revision 3453)
> +++
> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java
> (working copy)
> @@ -510,8 +510,8 @@
> */
> if (refType.isPrimitive()
> || refType.getPackage().equalsIgnoreCase("primitive")
> - || "java.lang.String".equalsIgnoreCase(refType
> - .getFullyQualifiedName())) {
> + ||
> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName())
> + ||
> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { //
> tigerstripe 1.7.0 now generates String and not java.lang.String
> PluginLog.logDebug("\'" + refTypeFullName
> + "\' is a primitive type in current TIP profile.");
> type = mapPrimitivesToXsdType(refType.getName(),
> isArray(refType),
> @@ -519,7 +519,7 @@
> }
>
> /**
> - * Map datatyeps and enumerations
> + * Map datatypes and enumerations
> */
> // if (refType.isDatatype() || refType.isEnum()
> else if (isDatatype(refType) || isEnumeration(refType)) {
> Index:
> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java
> ===================================================================
> ---
> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java
> (revision 3453)
> +++
> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java
> (working copy)
> @@ -170,8 +170,9 @@
> private void addReferencedPackage(IType type) {
>
> if (type.isPrimitive()
> - || "primitive".equalsIgnoreCase(type.getPackage()) ||
> -
> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) {
> + || "primitive".equalsIgnoreCase(type.getPackage())
> + ||
> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())
> + ||
> "String".equalsIgnoreCase(type.getFullyQualifiedName())) { //
> tigerstripe 1.7.0 now generates String and not java.lang.String
> //will map objectName to EntityIdentifier or
> ArrayOfEntityIdentifier
> if ("objectName".equalsIgnoreCase(type.getName())){
> PluginLog.logDebug("type \'" + type
> @@ -378,8 +379,8 @@
> */
> if (refType.isPrimitive()
> || refType.getPackage().equalsIgnoreCase("primitive")
> - || "java.lang.String".equalsIgnoreCase(refType
> - .getFullyQualifiedName())) {
> + ||
> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName())
> + ||
> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { //
> tigerstripe 1.7.0 now generates String and not java.lang.String
> PluginLog.logDebug("\'" + typeName
> + "\' is a primitive type in current TIP profile.");
>
>
>
>
>
>
>
> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote:
>
> Hi all. I think that I have found the error and I will try to fix it
> as soon as possible. There are some related issues, one error in the
> codification of a method and a forgetted evaluation of filtering in
> the velocity template and also a case related with primitive type
> filter not supported in the build of the closure outside the interfaces.
>
> In the interfaces build the search is performed as follows(this works
> fine as reported Marc):
>
> if ("objectName".equalsIgnoreCase(argType.getName())) {
> /*
> * This data type 'objectName' defines the
> protocol
> * neutral unique name of an object. This data
> type will
> * be replaced by the generators by an
> EntityIdentifier
> */
> String pkg = PluginConstants
>
> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG);
> if (!this.map.containsKey(pkg)) {
> //
> // New package - add new pkg=prefix mapping
> // assignment
> //
> String prefix =
> XmlSchemaHelpers.generateXmlPrefix(
> pkg, this.map);
> this.map.put(pkg, prefix);
> }
> } else if
> ("filter".equalsIgnoreCase(argType.getName())) {
> /*
> * This data type 'filter'. This data type will
> * be replaced by the generator to
> */
> String pkg = PluginConstants
>
> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG);
> if (!this.map.containsKey(pkg)) {
> //
> // New package - add new pkg=prefix mapping
> // assignment
> //
> String prefix =
> XmlSchemaHelpers.generateXmlPrefix(
> pkg, this.map);
> this.map.put(pkg, prefix);
> }
> } else if (XmlSchemaHelpers.isUnbounded(argType)) {
> String pkg = PluginConstants
>
> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG);
> if (!this.map.containsKey(pkg)) {
> //
> // New package - add new pkg=prefix mapping
> // assignment
> //
> String prefix =
> XmlSchemaHelpers.generateXmlPrefix(
> pkg, this.map);
> this.map.put(pkg, prefix);
> }
> } else {
> // XSD default namespace is enough
> }
>
> and in the build of the closure we have got (this fails as reported
> Craig):
>
> if ("objectName".equalsIgnoreCase(type.getName())){
> PluginLog.logDebug("type \'" + type
> + "\' is an array of primitive.");
> addReferencedPackage(PluginConstants
> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG));
> }else if (XmlSchemaHelpers.isUnbounded(type)){
> //will map to array of primitive
> addReferencedPackage(PluginConstants
>
> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG));
> } else {
> //normal primtive like xsd:int
> }
>
> so the filtering never is considered.
>
> I will perform clean tests because was very difficult to find the real
> cause of the problem, the log file is not very clear in debug
> scenarios ( a lot of similar log text, no log from the templates and
> also cannot put the line number in the log file (tigerstripe issue))
> and these problems have delayed my response.
> If the test go ok I will check out the changes to the trunk
>
> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator
>
> Best regards
>
>
> El 01/06/2012 16:58, Craig Gallen escribió:
>
> Hi,
>
> I agree it is defined in internal_filter.xsd but it doesn't seem to be
> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java
> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also
> shows an error.
>
> I think Xose is looking into it
>
> Craig
>
> -----Original Message-----
> From: Flauw, Marc [mailto:Mar...@hp...]
> Sent: 01 June 2012 10:25
> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre
> gauthier
> Subject: RE: Problems with PM XSD generation
>
> Craig,
>
> There is one same filter in the getReosurceAlarms operation, filter
> argument.
> The XPathFilter is defined in the internal_filter.xsd
>
> Best regards
>
> Marc
>
> -----Original Message-----
> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig
> Gallen (opennms)
> Sent: Thursday, May 31, 2012 11:58 PM
> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier
> Subject: Problems with PM XSD generation
>
> Hi,
>
> I have been testing the TIP_PM_Col project model and have found that the
> dep_cbe_perf_spec.xsd (attached) file is generated with errors
>
> in line 62 we have
> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter"
> minOccurs="0" maxOccurs="1">
>
> filter:XPathQueryFilter is not defined and if you open the file in eclipse
> it reports this error as:
>
> 's4s-att-invalid-value: Invalid attribute value for 'type' in element
> 'element'. Recorded reason:
> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName:
> the prefix 'filter' is not
> declared'.
>
> Is this a known problem or a new bug?
>
> Craig
>
>
> --
>
> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D
> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029
> www.optaresolutions.com
> <http://www.optaresolutions.com>
> Optare Solutions <http://optarecoolvendor.com>
>
|
|
From: Xose R. S. V. <xr...@op...> - 2012-06-26 08:40:30
|
Thanks Craig. I have performed some test and I can see an error in the Default Velocity context contents. When the $allPackage variable is used in the dependencyAnalyzer.vm template, it is expected that all artifacts, including the dependences, are included in that collection. In my tests I've got this behaivour: Old version of tigerstripe( Tigerstripe Core (Incubation) 0.6.935.201102010903 org.eclipse.tigerstripe.base.feature.group) %%%Calculate the dependencies/closure with [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), org.tmforum.tip.resource(240211633), org.tmforum.tip.cbe.perf(1039318676), org.tmforum.tip.common.notifications(23492680), org.tmforum.tip.resource.res(1133197283), org.tmforum.tip.cbe.root(1039387789), org.tmforum.tip(-660924437), org.tmforum.tip.cbe.root._char(-1449023596), org.tmforum(1644248382), org(110308), org.tmforum.tip.common(442435918), org.tmforum.tip.cbe.party(-2140978021), org.tmforum.tip.cbe.problem(292836116), org.tmforum.tip.cbe.root.tip.fmk(693071952), org.tmforum.tip.internal.filter(-1708340282), org.tmforum.tip.internal.extensibility(-1665414181), org.tmforum.tip.internal(1151687008), org.tmforum.tip.cbe.root.tip(1325885370), org.tmforum.tip.internal.notifications(-1680981798), org.tmforum.tip.common.exceptions(234099364), org.tmforum.tip.cbe.party.role(1514413545), org.tmforum.tip.internal.entity(-1732123599), org.tmforum.tip.resource.res.tip(-1716701168), org.tmforum.tip.internal.exceptions(-367434926), org.tmforum.tip.cbe(1681757027), org.tmforum.tip.internal.iterator(866200892), org.tmforum.tip.resource.res.tip.nrb(290014272)] [2012-06-26 10:21:29.996+0200] New version og tigerstripe( Tigerstripe Core (Incubation) 0.7.0.201206181258 org.eclipse.tigerstripe.base.feature.group): %%%Calculate the dependencies/closure with [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), org.tmforum.tip.resource(240211633)] [2012-06-26 10:28:54.989+0200] So it seems that this is root cause for the missed files. I will create a bug in Tigerstripe. Regards El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: > Hi > From eclipse, Soap generator subversion; > https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator > Revision 3453 > (last change revision 3444 last commit author xrsousa) > > Craig > > On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >> Hi Craig, when you talk about the updated Soap Plugin, which version >> (in svn url) are using?, because the two first issues seems to be >> solved in the trunk with the other Tigerstripe version. >> >> >> >> >> Regards >> El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: >>> Hi Xose, >>> >>> I just updated my tigerstripe to the latest release >>> 0.7.0.20120618258 but Ialso updated the Soap plug-in and have found >>> multiple problems but I am not sure if they are all related to the >>> tigerstripe upgrade or to the current state of the soap plugin. >>> Could you build the RAM project and check the generated XSD's to see >>> the problem. >>> >>> 1. when you build the RAM project there is a problem with model >>> closure. None of the Dependency XSD's get generated in the >>> RAM_Model project >>> >>> 2. TrackingRecordResultWithIterator referenced as >>> 'problem:TrackingRecordResultWithIterator' in >>> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd is >>> never generated. >>> >>> 3. Tigerstripe 0.7.0.20120618258. handles primitive.string >>> differently and generates type 'String' instead of >>> 'java.lang.String' this results in type :String instead of >>> xsd:string. I did a quick fix given in the following patch adding >>> || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>> >>> to >>> || "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>> this means that old and new versions of tigerstipe will work >>> >>> There is a patch below but havent checked this in because I was not >>> sure that else you were doing to the Soap plugin >>> >>> Craig >>> >>> >>> >>> ### Eclipse Workspace Patch 1.0 >>> #P TIP_Soap_Generator >>> Index: >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>> =================================================================== >>> --- >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>> (revision 3453) >>> +++ >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>> (working copy) >>> @@ -510,8 +510,8 @@ >>> */ >>> if (refType.isPrimitive() >>> || refType.getPackage().equalsIgnoreCase("primitive") >>> - || "java.lang.String".equalsIgnoreCase(refType >>> - .getFullyQualifiedName())) { >>> + || >>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>> + || >>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { // >>> tigerstripe 1.7.0 now generates String and not java.lang.String >>> PluginLog.logDebug("\'" + refTypeFullName >>> + "\' is a primitive type in current TIP >>> profile."); >>> type = mapPrimitivesToXsdType(refType.getName(), >>> isArray(refType), >>> @@ -519,7 +519,7 @@ >>> } >>> >>> /** >>> - * Map datatyeps and enumerations >>> + * Map datatypes and enumerations >>> */ >>> // if (refType.isDatatype() || refType.isEnum() >>> else if (isDatatype(refType) || isEnumeration(refType)) { >>> Index: >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>> =================================================================== >>> --- >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>> (revision 3453) >>> +++ >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>> (working copy) >>> @@ -170,8 +170,9 @@ >>> private void addReferencedPackage(IType type) { >>> >>> if (type.isPrimitive() >>> - || "primitive".equalsIgnoreCase(type.getPackage()) || >>> - >>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) { >>> + || "primitive".equalsIgnoreCase(type.getPackage()) >>> + || >>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>> + || >>> "String".equalsIgnoreCase(type.getFullyQualifiedName())) { // >>> tigerstripe 1.7.0 now generates String and not java.lang.String >>> //will map objectName to EntityIdentifier or >>> ArrayOfEntityIdentifier >>> if ("objectName".equalsIgnoreCase(type.getName())){ >>> PluginLog.logDebug("type \'" + type >>> @@ -378,8 +379,8 @@ >>> */ >>> if (refType.isPrimitive() >>> || refType.getPackage().equalsIgnoreCase("primitive") >>> - || "java.lang.String".equalsIgnoreCase(refType >>> - .getFullyQualifiedName())) { >>> + || >>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>> + || >>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { // >>> tigerstripe 1.7.0 now generates String and not java.lang.String >>> PluginLog.logDebug("\'" + typeName >>> + "\' is a primitive type in current TIP >>> profile."); >>> >>> >>> >>> >>> >>> >>> >>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>>> Hi all. I think that I have found the error and I will try to fix >>>> it as soon as possible. There are some related issues, one error in >>>> the codification of a method and a forgetted evaluation of >>>> filtering in the velocity template and also a case related with >>>> primitive type filter not supported in the build of the closure >>>> outside the interfaces. >>>> >>>> In the interfaces build the search is performed as follows(this >>>> works fine as reported Marc): >>>> >>>> if ("objectName".equalsIgnoreCase(argType.getName())) { >>>> /* >>>> * This data type 'objectName' defines >>>> the protocol >>>> * neutral unique name of an object. >>>> This data type will >>>> * be replaced by the generators by an >>>> EntityIdentifier >>>> */ >>>> String pkg = PluginConstants >>>> >>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>>> if (!this.map.containsKey(pkg)) { >>>> // >>>> // New package - add new pkg=prefix >>>> mapping >>>> // assignment >>>> // >>>> String prefix = >>>> XmlSchemaHelpers.generateXmlPrefix( >>>> pkg, this.map); >>>> this.map.put(pkg, prefix); >>>> } >>>> } else if >>>> ("filter".equalsIgnoreCase(argType.getName())) { >>>> /* >>>> * This data type 'filter'. This data >>>> type will >>>> * be replaced by the generator to >>>> */ >>>> String pkg = PluginConstants >>>> >>>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >>>> if (!this.map.containsKey(pkg)) { >>>> // >>>> // New package - add new pkg=prefix >>>> mapping >>>> // assignment >>>> // >>>> String prefix = >>>> XmlSchemaHelpers.generateXmlPrefix( >>>> pkg, this.map); >>>> this.map.put(pkg, prefix); >>>> } >>>> } else if >>>> (XmlSchemaHelpers.isUnbounded(argType)) { >>>> String pkg = PluginConstants >>>> >>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >>>> if (!this.map.containsKey(pkg)) { >>>> // >>>> // New package - add new pkg=prefix >>>> mapping >>>> // assignment >>>> // >>>> String prefix = >>>> XmlSchemaHelpers.generateXmlPrefix( >>>> pkg, this.map); >>>> this.map.put(pkg, prefix); >>>> } >>>> } else { >>>> // XSD default namespace is enough >>>> } >>>> >>>> and in the build of the closure we have got (this fails as reported >>>> Craig): >>>> >>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>> PluginLog.logDebug("type \'" + type >>>> + "\' is an array of primitive."); >>>> addReferencedPackage(PluginConstants >>>> >>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >>>> }else if (XmlSchemaHelpers.isUnbounded(type)){ >>>> //will map to array of primitive >>>> addReferencedPackage(PluginConstants >>>> >>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >>>> } else { >>>> //normal primtive like xsd:int >>>> } >>>> >>>> so the filtering never is considered. >>>> >>>> I will perform clean tests because was very difficult to find the >>>> real cause of the problem, the log file is not very clear in debug >>>> scenarios ( a lot of similar log text, no log from the templates >>>> and also cannot put the line number in the log file (tigerstripe >>>> issue)) and these problems have delayed my response. >>>> If the test go ok I will check out the changes to the trunk >>>> >>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>> >>>> Best regards >>>> >>>> >>>> El 01/06/2012 16:58, Craig Gallen escribió: >>>>> Hi, >>>>> >>>>> I agree it is defined in internal_filter.xsd but it doesn't seem to be >>>>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >>>>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >>>>> shows an error. >>>>> >>>>> I think Xose is looking into it >>>>> >>>>> Craig >>>>> >>>>> -----Original Message----- >>>>> From: Flauw, Marc [mailto:Mar...@hp...] >>>>> Sent: 01 June 2012 10:25 >>>>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >>>>> gauthier >>>>> Subject: RE: Problems with PM XSD generation >>>>> >>>>> Craig, >>>>> >>>>> There is one same filter in the getReosurceAlarms operation, filter >>>>> argument. >>>>> The XPathFilter is defined in the internal_filter.xsd >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> -----Original Message----- >>>>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >>>>> Gallen (opennms) >>>>> Sent: Thursday, May 31, 2012 11:58 PM >>>>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >>>>> Subject: Problems with PM XSD generation >>>>> >>>>> Hi, >>>>> >>>>> I have been testing the TIP_PM_Col project model and have found that the >>>>> dep_cbe_perf_spec.xsd (attached) file is generated with errors >>>>> >>>>> in line 62 we have >>>>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >>>>> minOccurs="0" maxOccurs="1"> >>>>> >>>>> filter:XPathQueryFilter is not defined and if you open the file in eclipse >>>>> it reports this error as: >>>>> >>>>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >>>>> 'element'. Recorded reason: >>>>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >>>>> the prefix 'filter' is not >>>>> declared'. >>>>> >>>>> Is this a known problem or a new bug? >>>>> >>>>> Craig >>>>> >>>> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions >>>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>>> >> >> >> -- >> >> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions >> <http://optarecoolvendor.com><http://optarecoolvendor.com> >> -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Pierre g. <pie...@os...> - 2012-06-26 17:23:26
|
Hi Craig, Looks like we have regression testing issues with this Tigerstripe version. Can we wait until we finish regression testing before moving to this version of TigerStripe ? Also what is the status of the build ? Pierre Le 2012-06-26 à 11:03, "Craig Gallen (entimoss)" <cra...@en...> a écrit : > Hi, > > So is there a work around or do we have to wait for Tigerstripe to sort this out. > The old version of tigerstripe (6.9.xxx) is no longer available to download. > > Craig > > > On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >> Thanks Craig. >> I have performed some test and I can see an error in the Default Velocity context contents. When the $allPackage variable is used in the dependencyAnalyzer.vm template, it is expected that all artifacts, including the dependences, are included in that collection. In my tests I've got this behaivour: >> >> Old version of tigerstripe( Tigerstripe Core (Incubation) 0.6.935.201102010903 org.eclipse.tigerstripe.base.feature.group) >> %%%Calculate the dependencies/closure with [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), org.tmforum.tip.resource(240211633), org.tmforum.tip.cbe.perf(1039318676), org.tmforum.tip.common.notifications(23492680), org.tmforum.tip.resource.res(1133197283), org.tmforum.tip.cbe.root(1039387789), org.tmforum.tip(-660924437), org.tmforum.tip.cbe.root._char(-1449023596), org.tmforum(1644248382), org(110308), org.tmforum.tip.common(442435918), org.tmforum.tip.cbe.party(-2140978021), org.tmforum.tip.cbe.problem(292836116), org.tmforum.tip.cbe.root.tip.fmk(693071952), org.tmforum.tip.internal.filter(-1708340282), org.tmforum.tip.internal.extensibility(-1665414181), org.tmforum.tip.internal(1151687008), org.tmforum.tip.cbe.root.tip(1325885370), org.tmforum.tip.internal.notifications(-1680981798), org.tmforum.tip.common.exceptions(234099364), org.tmforum.tip.cbe.party.role(1514413545), org.tmforum.tip.internal.entity(-1732123599), org.tmforum.tip.resource.res.tip(-1716701168), org.tmforum.tip.internal.exceptions(-367434926), org.tmforum.tip.cbe(1681757027), org.tmforum.tip.internal.iterator(866200892), org.tmforum.tip.resource.res.tip.nrb(290014272)] [2012-06-26 10:21:29.996+0200] >> >> New version og tigerstripe( Tigerstripe Core (Incubation) 0.7.0.201206181258 org.eclipse.tigerstripe.base.feature.group): >> %%%Calculate the dependencies/closure with [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), org.tmforum.tip.resource(240211633)] [2012-06-26 10:28:54.989+0200] >> >> So it seems that this is root cause for the missed files. >> I will create a bug in Tigerstripe. >> >> Regards >> >> El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: >>> >>> Hi >>> From eclipse, Soap generator subversion; >>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>> Revision 3453 >>> (last change revision 3444 last commit author xrsousa) >>> >>> Craig >>> >>> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >>>> >>>> Hi Craig, when you talk about the updated Soap Plugin, which version (in svn url) are using?, because the two first issues seems to be solved in the trunk with the other Tigerstripe version. >>>> >>>> >>>> >>>> >>>> Regards >>>> El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: >>>>> >>>>> Hi Xose, >>>>> >>>>> I just updated my tigerstripe to the latest release 0.7.0.20120618258 but Ialso updated the Soap plug-in and have found multiple problems but I am not sure if they are all related to the tigerstripe upgrade or to the current state of the soap plugin. Could you build the RAM project and check the generated XSD's to see the problem. >>>>> >>>>> 1. when you build the RAM project there is a problem with model closure. None of the Dependency XSD's get generated in the RAM_Model project >>>>> >>>>> 2. TrackingRecordResultWithIterator referenced as 'problem:TrackingRecordResultWithIterator' in ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd is never generated. >>>>> >>>>> 3. Tigerstripe 0.7.0.20120618258. handles primitive.string differently and generates type 'String' instead of 'java.lang.String' this results in type :String instead of xsd:string. I did a quick fix given in the following patch adding >>>>> || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>> >>>>> to >>>>> || "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> this means that old and new versions of tigerstipe will work >>>>> >>>>> There is a patch below but havent checked this in because I was not sure that else you were doing to the Soap plugin >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> ### Eclipse Workspace Patch 1.0 >>>>> #P TIP_Soap_Generator >>>>> Index: src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> =================================================================== >>>>> --- src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java (revision 3453) >>>>> +++ src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java (working copy) >>>>> @@ -510,8 +510,8 @@ >>>>> */ >>>>> if (refType.isPrimitive() >>>>> || refType.getPackage().equalsIgnoreCase("primitive") >>>>> - || "java.lang.String".equalsIgnoreCase(refType >>>>> - .getFullyQualifiedName())) { >>>>> + || "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> + || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { // tigerstripe 1.7.0 now generates String and not java.lang.String >>>>> PluginLog.logDebug("\'" + refTypeFullName >>>>> + "\' is a primitive type in current TIP profile."); >>>>> type = mapPrimitivesToXsdType(refType.getName(), isArray(refType), >>>>> @@ -519,7 +519,7 @@ >>>>> } >>>>> >>>>> /** >>>>> - * Map datatyeps and enumerations >>>>> + * Map datatypes and enumerations >>>>> */ >>>>> // if (refType.isDatatype() || refType.isEnum() >>>>> else if (isDatatype(refType) || isEnumeration(refType)) { >>>>> Index: src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> =================================================================== >>>>> --- src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java (revision 3453) >>>>> +++ src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java (working copy) >>>>> @@ -170,8 +170,9 @@ >>>>> private void addReferencedPackage(IType type) { >>>>> >>>>> if (type.isPrimitive() >>>>> - || "primitive".equalsIgnoreCase(type.getPackage()) || >>>>> - "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) { >>>>> + || "primitive".equalsIgnoreCase(type.getPackage()) >>>>> + || "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>>>> + || "String".equalsIgnoreCase(type.getFullyQualifiedName())) { // tigerstripe 1.7.0 now generates String and not java.lang.String >>>>> //will map objectName to EntityIdentifier or ArrayOfEntityIdentifier >>>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>>> PluginLog.logDebug("type \'" + type >>>>> @@ -378,8 +379,8 @@ >>>>> */ >>>>> if (refType.isPrimitive() >>>>> || refType.getPackage().equalsIgnoreCase("primitive") >>>>> - || "java.lang.String".equalsIgnoreCase(refType >>>>> - .getFullyQualifiedName())) { >>>>> + || "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> + || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { // tigerstripe 1.7.0 now generates String and not java.lang.String >>>>> PluginLog.logDebug("\'" + typeName >>>>> + "\' is a primitive type in current TIP profile."); >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>>>>> >>>>>> Hi all. I think that I have found the error and I will try to fix it as soon as possible. There are some related issues, one error in the codification of a method and a forgetted evaluation of filtering in the velocity template and also a case related with primitive type filter not supported in the build of the closure outside the interfaces. >>>>>> >>>>>> In the interfaces build the search is performed as follows(this works fine as reported Marc): >>>>>> if ("objectName".equalsIgnoreCase(argType.getName())) { >>>>>> /* >>>>>> * This data type 'objectName' defines the protocol >>>>>> * neutral unique name of an object. This data type will >>>>>> * be replaced by the generators by an EntityIdentifier >>>>>> */ >>>>>> String pkg = PluginConstants >>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>>>>> if (!this.map.containsKey(pkg)) { >>>>>> |
|
From: Xose R. S. V. <xr...@op...> - 2012-06-27 09:02:05
|
I am going to test a workaround to see if this could be supported without change the tigerstripe core. Regards El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: > Hi, > > So is there a work around or do we have to wait for Tigerstripe to > sort this out. > The old version of tigerstripe (6.9.xxx) is no longer available to > download. > > Craig > > > On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >> Thanks Craig. >> I have performed some test and I can see an error in the Default >> Velocity context contents. When the $allPackage variable is used in >> the dependencyAnalyzer.vm template, it is expected that all >> artifacts, including the dependences, are included in that >> collection. In my tests I've got this behaivour: >> >> Old version of tigerstripe( Tigerstripe Core (Incubation) >> 0.6.935.201102010903 org.eclipse.tigerstripe.base.feature.group) >> %%%Calculate the dependencies/closure with >> [org.tmforum.tip.resource.trouble.alarm(370509597), >> org.tmforum.tip.resource.trouble(428889018), >> org.tmforum.tip.resource(240211633), >> org.tmforum.tip.cbe.perf(1039318676), >> org.tmforum.tip.common.notifications(23492680), >> org.tmforum.tip.resource.res(1133197283), >> org.tmforum.tip.cbe.root(1039387789), org.tmforum.tip(-660924437), >> org.tmforum.tip.cbe.root._char(-1449023596), org.tmforum(1644248382), >> org(110308), org.tmforum.tip.common(442435918), >> org.tmforum.tip.cbe.party(-2140978021), >> org.tmforum.tip.cbe.problem(292836116), >> org.tmforum.tip.cbe.root.tip.fmk(693071952), >> org.tmforum.tip.internal.filter(-1708340282), >> org.tmforum.tip.internal.extensibility(-1665414181), >> org.tmforum.tip.internal(1151687008), >> org.tmforum.tip.cbe.root.tip(1325885370), >> org.tmforum.tip.internal.notifications(-1680981798), >> org.tmforum.tip.common.exceptions(234099364), >> org.tmforum.tip.cbe.party.role(1514413545), >> org.tmforum.tip.internal.entity(-1732123599), >> org.tmforum.tip.resource.res.tip(-1716701168), >> org.tmforum.tip.internal.exceptions(-367434926), >> org.tmforum.tip.cbe(1681757027), >> org.tmforum.tip.internal.iterator(866200892), >> org.tmforum.tip.resource.res.tip.nrb(290014272)] [2012-06-26 >> 10:21:29.996+0200] >> >> New version og tigerstripe( Tigerstripe Core (Incubation) >> 0.7.0.201206181258 org.eclipse.tigerstripe.base.feature.group): >> %%%Calculate the dependencies/closure with >> [org.tmforum.tip.resource.trouble.alarm(370509597), >> org.tmforum.tip.resource.trouble(428889018), >> org.tmforum.tip.resource(240211633)] [2012-06-26 10:28:54.989+0200] >> >> So it seems that this is root cause for the missed files. >> I will create a bug in Tigerstripe. >> >> Regards >> >> El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: >>> Hi >>> From eclipse, Soap generator subversion; >>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>> Revision 3453 >>> (last change revision 3444 last commit author xrsousa) >>> >>> Craig >>> >>> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >>>> Hi Craig, when you talk about the updated Soap Plugin, which >>>> version (in svn url) are using?, because the two first issues seems >>>> to be solved in the trunk with the other Tigerstripe version. >>>> >>>> >>>> >>>> >>>> Regards >>>> El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: >>>>> Hi Xose, >>>>> >>>>> I just updated my tigerstripe to the latest release >>>>> 0.7.0.20120618258 but Ialso updated the Soap plug-in and have >>>>> found multiple problems but I am not sure if they are all related >>>>> to the tigerstripe upgrade or to the current state of the soap >>>>> plugin. Could you build the RAM project and check the generated >>>>> XSD's to see the problem. >>>>> >>>>> 1. when you build the RAM project there is a problem with model >>>>> closure. None of the Dependency XSD's get generated in the >>>>> RAM_Model project >>>>> >>>>> 2. TrackingRecordResultWithIterator referenced as >>>>> 'problem:TrackingRecordResultWithIterator' in >>>>> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd >>>>> is never generated. >>>>> >>>>> 3. Tigerstripe 0.7.0.20120618258. handles primitive.string >>>>> differently and generates type 'String' instead of >>>>> 'java.lang.String' this results in type :String instead of >>>>> xsd:string. I did a quick fix given in the following patch adding >>>>> || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>> >>>>> to >>>>> || >>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> this means that old and new versions of tigerstipe will work >>>>> >>>>> There is a patch below but havent checked this in because I was >>>>> not sure that else you were doing to the Soap plugin >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> ### Eclipse Workspace Patch 1.0 >>>>> #P TIP_Soap_Generator >>>>> Index: >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> =================================================================== >>>>> --- >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> (revision 3453) >>>>> +++ >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> (working copy) >>>>> @@ -510,8 +510,8 @@ >>>>> */ >>>>> if (refType.isPrimitive() >>>>> || refType.getPackage().equalsIgnoreCase("primitive") >>>>> - || "java.lang.String".equalsIgnoreCase(refType >>>>> - .getFullyQualifiedName())) { >>>>> + || >>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> + || >>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { // >>>>> tigerstripe 1.7.0 now generates String and not java.lang.String >>>>> PluginLog.logDebug("\'" + refTypeFullName >>>>> + "\' is a primitive type in current TIP >>>>> profile."); >>>>> type = mapPrimitivesToXsdType(refType.getName(), >>>>> isArray(refType), >>>>> @@ -519,7 +519,7 @@ >>>>> } >>>>> >>>>> /** >>>>> - * Map datatyeps and enumerations >>>>> + * Map datatypes and enumerations >>>>> */ >>>>> // if (refType.isDatatype() || refType.isEnum() >>>>> else if (isDatatype(refType) || isEnumeration(refType)) { >>>>> Index: >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> =================================================================== >>>>> --- >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> (revision 3453) >>>>> +++ >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> (working copy) >>>>> @@ -170,8 +170,9 @@ >>>>> private void addReferencedPackage(IType type) { >>>>> >>>>> if (type.isPrimitive() >>>>> - || "primitive".equalsIgnoreCase(type.getPackage()) || >>>>> - "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) { >>>>> + || "primitive".equalsIgnoreCase(type.getPackage()) >>>>> + || >>>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>>>> + || >>>>> "String".equalsIgnoreCase(type.getFullyQualifiedName())) { // >>>>> tigerstripe 1.7.0 now generates String and not java.lang.String >>>>> //will map objectName to EntityIdentifier or >>>>> ArrayOfEntityIdentifier >>>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>>> PluginLog.logDebug("type \'" + type >>>>> @@ -378,8 +379,8 @@ >>>>> */ >>>>> if (refType.isPrimitive() >>>>> || refType.getPackage().equalsIgnoreCase("primitive") >>>>> - || "java.lang.String".equalsIgnoreCase(refType >>>>> - .getFullyQualifiedName())) { >>>>> + || >>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> + || >>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { // >>>>> tigerstripe 1.7.0 now generates String and not java.lang.String >>>>> PluginLog.logDebug("\'" + typeName >>>>> + "\' is a primitive type in current TIP >>>>> profile."); >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>>>>> Hi all. I think that I have found the error and I will try to fix >>>>>> it as soon as possible. There are some related issues, one error >>>>>> in the codification of a method and a forgetted evaluation of >>>>>> filtering in the velocity template and also a case related with >>>>>> primitive type filter not supported in the build of the closure >>>>>> outside the interfaces. >>>>>> >>>>>> In the interfaces build the search is performed as follows(this >>>>>> works fine as reported Marc): >>>>>> >>>>>> if >>>>>> ("objectName".equalsIgnoreCase(argType.getName())) { >>>>>> /* >>>>>> * This data type 'objectName' >>>>>> defines the protocol >>>>>> * neutral unique name of an object. >>>>>> This data type will >>>>>> * be replaced by the generators by >>>>>> an EntityIdentifier >>>>>> */ >>>>>> String pkg = PluginConstants >>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>>>>> if (!this.map.containsKey(pkg)) { >>>>>> // >>>>>> // New package - add new >>>>>> pkg=prefix mapping >>>>>> // assignment >>>>>> // >>>>>> String prefix = >>>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>>> pkg, this.map); >>>>>> this.map.put(pkg, prefix); >>>>>> } >>>>>> } else if >>>>>> ("filter".equalsIgnoreCase(argType.getName())) { >>>>>> /* >>>>>> * This data type 'filter'. This data >>>>>> type will >>>>>> * be replaced by the generator to >>>>>> */ >>>>>> String pkg = PluginConstants >>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >>>>>> if (!this.map.containsKey(pkg)) { >>>>>> // >>>>>> // New package - add new >>>>>> pkg=prefix mapping >>>>>> // assignment >>>>>> // >>>>>> String prefix = >>>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>>> pkg, this.map); >>>>>> this.map.put(pkg, prefix); >>>>>> } >>>>>> } else if >>>>>> (XmlSchemaHelpers.isUnbounded(argType)) { >>>>>> String pkg = PluginConstants >>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >>>>>> if (!this.map.containsKey(pkg)) { >>>>>> // >>>>>> // New package - add new >>>>>> pkg=prefix mapping >>>>>> // assignment >>>>>> // >>>>>> String prefix = >>>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>>> pkg, this.map); >>>>>> this.map.put(pkg, prefix); >>>>>> } >>>>>> } else { >>>>>> // XSD default namespace is enough >>>>>> } >>>>>> >>>>>> and in the build of the closure we have got (this fails as >>>>>> reported Craig): >>>>>> >>>>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>>>> PluginLog.logDebug("type \'" + type >>>>>> + "\' is an array of primitive."); >>>>>> addReferencedPackage(PluginConstants >>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >>>>>> }else if (XmlSchemaHelpers.isUnbounded(type)){ >>>>>> //will map to array of primitive >>>>>> addReferencedPackage(PluginConstants >>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >>>>>> } else { >>>>>> //normal primtive like xsd:int >>>>>> } >>>>>> >>>>>> so the filtering never is considered. >>>>>> >>>>>> I will perform clean tests because was very difficult to find the >>>>>> real cause of the problem, the log file is not very clear in >>>>>> debug scenarios ( a lot of similar log text, no log from the >>>>>> templates and also cannot put the line number in the log file >>>>>> (tigerstripe issue)) and these problems have delayed my response. >>>>>> If the test go ok I will check out the changes to the trunk >>>>>> >>>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>>>> >>>>>> Best regards >>>>>> >>>>>> >>>>>> El 01/06/2012 16:58, Craig Gallen escribió: >>>>>>> Hi, >>>>>>> >>>>>>> I agree it is defined in internal_filter.xsd but it doesn't seem to be >>>>>>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >>>>>>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >>>>>>> shows an error. >>>>>>> >>>>>>> I think Xose is looking into it >>>>>>> >>>>>>> Craig >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Flauw, Marc [mailto:Mar...@hp...] >>>>>>> Sent: 01 June 2012 10:25 >>>>>>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >>>>>>> gauthier >>>>>>> Subject: RE: Problems with PM XSD generation >>>>>>> >>>>>>> Craig, >>>>>>> >>>>>>> There is one same filter in the getReosurceAlarms operation, filter >>>>>>> argument. >>>>>>> The XPathFilter is defined in the internal_filter.xsd >>>>>>> >>>>>>> Best regards >>>>>>> >>>>>>> Marc >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >>>>>>> Gallen (opennms) >>>>>>> Sent: Thursday, May 31, 2012 11:58 PM >>>>>>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >>>>>>> Subject: Problems with PM XSD generation >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I have been testing the TIP_PM_Col project model and have found that the >>>>>>> dep_cbe_perf_spec.xsd (attached) file is generated with errors >>>>>>> >>>>>>> in line 62 we have >>>>>>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >>>>>>> minOccurs="0" maxOccurs="1"> >>>>>>> >>>>>>> filter:XPathQueryFilter is not defined and if you open the file in eclipse >>>>>>> it reports this error as: >>>>>>> >>>>>>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >>>>>>> 'element'. Recorded reason: >>>>>>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >>>>>>> the prefix 'filter' is not >>>>>>> declared'. >>>>>>> >>>>>>> Is this a known problem or a new bug? >>>>>>> >>>>>>> Craig >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >>>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>>> www.optaresolutions.com >>>>>> <http://www.optaresolutions.com> >>>>>> Optare Solutions >>>>>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>>>>> >>>> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions >>>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>>> >> >> >> -- >> >> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions >> <http://optarecoolvendor.com><http://optarecoolvendor.com> >> > > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Craig G. (opennms) <cg...@op...> - 2012-06-28 04:32:14
|
Xose & Marc, Is there a plan to complete primitive.url / primitive.uri in the soap generator. I have support for it in the Java generators but need the Soap generator working with this stereotype to test this code. Also has a bug been raised against Tigerstripe for the $allPackage issue ? I'd prefer to fix the problem in tigerstripe rather than have Xose get a work around because if this isnt working, its possible other 'get all collections' of artificates are not working. So this could be a general problem for the other generators including Cisco's own. Xose, have you raised a bug report and if so what is the bug number? Marc, when we have a bug report, can we escalate this directly to the tigerstripe team because it is a show stopper for us. I'm afraid I cannot do any more development until this is fixed. Thanks for your help Craig > > > > On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: >> I am going to test a workaround to see if this could be supported >> without change the tigerstripe core. >> >> Regards >> El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: >>> Hi, >>> >>> So is there a work around or do we have to wait for Tigerstripe to >>> sort this out. >>> The old version of tigerstripe (6.9.xxx) is no longer available to >>> download. >>> >>> Craig >>> >>> >>> On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >>>> Thanks Craig. >>>> I have performed some test and I can see an error in the Default >>>> Velocity context contents. When the $allPackage variable is used in >>>> the dependencyAnalyzer.vm template, it is expected that all >>>> artifacts, including the dependences, are included in that >>>> collection. In my tests I've got this behaivour: >>>> >>>> Old version of tigerstripe( Tigerstripe Core (Incubation) >>>> 0.6.935.201102010903 org.eclipse.tigerstripe.base.feature.group) >>>> %%%Calculate the dependencies/closure with >>>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>>> org.tmforum.tip.resource.trouble(428889018), >>>> org.tmforum.tip.resource(240211633), >>>> org.tmforum.tip.cbe.perf(1039318676), >>>> org.tmforum.tip.common.notifications(23492680), >>>> org.tmforum.tip.resource.res(1133197283), >>>> org.tmforum.tip.cbe.root(1039387789), org.tmforum.tip(-660924437), >>>> org.tmforum.tip.cbe.root._char(-1449023596), >>>> org.tmforum(1644248382), org(110308), >>>> org.tmforum.tip.common(442435918), >>>> org.tmforum.tip.cbe.party(-2140978021), >>>> org.tmforum.tip.cbe.problem(292836116), >>>> org.tmforum.tip.cbe.root.tip.fmk(693071952), >>>> org.tmforum.tip.internal.filter(-1708340282), >>>> org.tmforum.tip.internal.extensibility(-1665414181), >>>> org.tmforum.tip.internal(1151687008), >>>> org.tmforum.tip.cbe.root.tip(1325885370), >>>> org.tmforum.tip.internal.notifications(-1680981798), >>>> org.tmforum.tip.common.exceptions(234099364), >>>> org.tmforum.tip.cbe.party.role(1514413545), >>>> org.tmforum.tip.internal.entity(-1732123599), >>>> org.tmforum.tip.resource.res.tip(-1716701168), >>>> org.tmforum.tip.internal.exceptions(-367434926), >>>> org.tmforum.tip.cbe(1681757027), >>>> org.tmforum.tip.internal.iterator(866200892), >>>> org.tmforum.tip.resource.res.tip.nrb(290014272)] [2012-06-26 >>>> 10:21:29.996+0200] >>>> >>>> New version og tigerstripe( Tigerstripe Core (Incubation) >>>> 0.7.0.201206181258 org.eclipse.tigerstripe.base.feature.group): >>>> %%%Calculate the dependencies/closure with >>>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>>> org.tmforum.tip.resource.trouble(428889018), >>>> org.tmforum.tip.resource(240211633)] [2012-06-26 10:28:54.989+0200] >>>> >>>> So it seems that this is root cause for the missed files. >>>> I will create a bug in Tigerstripe. >>>> >>>> Regards >>>> >>>> El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: >>>>> Hi >>>>> From eclipse, Soap generator subversion; >>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>>> Revision 3453 >>>>> (last change revision 3444 last commit author xrsousa) >>>>> >>>>> Craig >>>>> >>>>> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >>>>>> Hi Craig, when you talk about the updated Soap Plugin, which >>>>>> version (in svn url) are using?, because the two first issues >>>>>> seems to be solved in the trunk with the other Tigerstripe version. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Regards >>>>>> El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: >>>>>>> Hi Xose, >>>>>>> >>>>>>> I just updated my tigerstripe to the latest release >>>>>>> 0.7.0.20120618258 but Ialso updated the Soap plug-in and have >>>>>>> found multiple problems but I am not sure if they are all >>>>>>> related to the tigerstripe upgrade or to the current state of >>>>>>> the soap plugin. Could you build the RAM project and check the >>>>>>> generated XSD's to see the problem. >>>>>>> >>>>>>> 1. when you build the RAM project there is a problem with model >>>>>>> closure. None of the Dependency XSD's get generated in the >>>>>>> RAM_Model project >>>>>>> >>>>>>> 2. TrackingRecordResultWithIterator referenced as >>>>>>> 'problem:TrackingRecordResultWithIterator' in >>>>>>> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd >>>>>>> is never generated. >>>>>>> >>>>>>> 3. Tigerstripe 0.7.0.20120618258. handles primitive.string >>>>>>> differently and generates type 'String' instead of >>>>>>> 'java.lang.String' this results in type :String instead of >>>>>>> xsd:string. I did a quick fix given in the following patch adding >>>>>>> || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>>>> >>>>>>> to >>>>>>> || >>>>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>>>> this means that old and new versions of tigerstipe will work >>>>>>> >>>>>>> There is a patch below but havent checked this in because I was >>>>>>> not sure that else you were doing to the Soap plugin >>>>>>> >>>>>>> Craig >>>>>>> >>>>>>> >>>>>>> >>>>>>> ### Eclipse Workspace Patch 1.0 >>>>>>> #P TIP_Soap_Generator >>>>>>> Index: >>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>>>> =================================================================== >>>>>>> --- >>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>>>> (revision 3453) >>>>>>> +++ >>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>>>> (working copy) >>>>>>> @@ -510,8 +510,8 @@ >>>>>>> */ >>>>>>> if (refType.isPrimitive() >>>>>>> || >>>>>>> refType.getPackage().equalsIgnoreCase("primitive") >>>>>>> - || "java.lang.String".equalsIgnoreCase(refType >>>>>>> - .getFullyQualifiedName())) { >>>>>>> + || >>>>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>>>> + || >>>>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { // >>>>>>> tigerstripe 1.7.0 now generates String and not java.lang.String >>>>>>> PluginLog.logDebug("\'" + refTypeFullName >>>>>>> + "\' is a primitive type in current TIP >>>>>>> profile."); >>>>>>> type = mapPrimitivesToXsdType(refType.getName(), >>>>>>> isArray(refType), >>>>>>> @@ -519,7 +519,7 @@ >>>>>>> } >>>>>>> >>>>>>> /** >>>>>>> - * Map datatyeps and enumerations >>>>>>> + * Map datatypes and enumerations >>>>>>> */ >>>>>>> // if (refType.isDatatype() || refType.isEnum() >>>>>>> else if (isDatatype(refType) || isEnumeration(refType)) { >>>>>>> Index: >>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>>>> =================================================================== >>>>>>> --- >>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>>>> (revision 3453) >>>>>>> +++ >>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>>>> (working copy) >>>>>>> @@ -170,8 +170,9 @@ >>>>>>> private void addReferencedPackage(IType type) { >>>>>>> >>>>>>> if (type.isPrimitive() >>>>>>> - || >>>>>>> "primitive".equalsIgnoreCase(type.getPackage()) || >>>>>>> - >>>>>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) { >>>>>>> + || "primitive".equalsIgnoreCase(type.getPackage()) >>>>>>> + || >>>>>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>>>>>> + || >>>>>>> "String".equalsIgnoreCase(type.getFullyQualifiedName())) { // >>>>>>> tigerstripe 1.7.0 now generates String and not java.lang.String >>>>>>> //will map objectName to EntityIdentifier or >>>>>>> ArrayOfEntityIdentifier >>>>>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>>>>> PluginLog.logDebug("type \'" + type >>>>>>> @@ -378,8 +379,8 @@ >>>>>>> */ >>>>>>> if (refType.isPrimitive() >>>>>>> || >>>>>>> refType.getPackage().equalsIgnoreCase("primitive") >>>>>>> - || "java.lang.String".equalsIgnoreCase(refType >>>>>>> - .getFullyQualifiedName())) { >>>>>>> + || >>>>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>>>> + || >>>>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { // >>>>>>> tigerstripe 1.7.0 now generates String and not java.lang.String >>>>>>> PluginLog.logDebug("\'" + typeName >>>>>>> + "\' is a primitive type in current TIP >>>>>>> profile."); >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>>>>>>> Hi all. I think that I have found the error and I will try to >>>>>>>> fix it as soon as possible. There are some related issues, one >>>>>>>> error in the codification of a method and a forgetted >>>>>>>> evaluation of filtering in the velocity template and also a >>>>>>>> case related with primitive type filter not supported in the >>>>>>>> build of the closure outside the interfaces. >>>>>>>> >>>>>>>> In the interfaces build the search is performed as follows(this >>>>>>>> works fine as reported Marc): >>>>>>>> >>>>>>>> if >>>>>>>> ("objectName".equalsIgnoreCase(argType.getName())) { >>>>>>>> /* >>>>>>>> * This data type 'objectName' >>>>>>>> defines the protocol >>>>>>>> * neutral unique name of an >>>>>>>> object. This data type will >>>>>>>> * be replaced by the generators by >>>>>>>> an EntityIdentifier >>>>>>>> */ >>>>>>>> String pkg = PluginConstants >>>>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>>>>>>> if (!this.map.containsKey(pkg)) { >>>>>>>> // >>>>>>>> // New package - add new >>>>>>>> pkg=prefix mapping >>>>>>>> // assignment >>>>>>>> // >>>>>>>> String prefix = >>>>>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>>>>> pkg, this.map); >>>>>>>> this.map.put(pkg, prefix); >>>>>>>> } >>>>>>>> } else if >>>>>>>> ("filter".equalsIgnoreCase(argType.getName())) { >>>>>>>> /* >>>>>>>> * This data type 'filter'. This >>>>>>>> data type will >>>>>>>> * be replaced by the generator to >>>>>>>> */ >>>>>>>> String pkg = PluginConstants >>>>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >>>>>>>> if (!this.map.containsKey(pkg)) { >>>>>>>> // >>>>>>>> // New package - add new >>>>>>>> pkg=prefix mapping >>>>>>>> // assignment >>>>>>>> // >>>>>>>> String prefix = >>>>>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>>>>> pkg, this.map); >>>>>>>> this.map.put(pkg, prefix); >>>>>>>> } >>>>>>>> } else if >>>>>>>> (XmlSchemaHelpers.isUnbounded(argType)) { >>>>>>>> String pkg = PluginConstants >>>>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >>>>>>>> if (!this.map.containsKey(pkg)) { >>>>>>>> // >>>>>>>> // New package - add new >>>>>>>> pkg=prefix mapping >>>>>>>> // assignment >>>>>>>> // >>>>>>>> String prefix = >>>>>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>>>>> pkg, this.map); >>>>>>>> this.map.put(pkg, prefix); >>>>>>>> } >>>>>>>> } else { >>>>>>>> // XSD default namespace is enough >>>>>>>> } >>>>>>>> >>>>>>>> and in the build of the closure we have got (this fails as >>>>>>>> reported Craig): >>>>>>>> >>>>>>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>>>>>> PluginLog.logDebug("type \'" + type >>>>>>>> + "\' is an array of primitive."); >>>>>>>> addReferencedPackage(PluginConstants >>>>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >>>>>>>> }else if (XmlSchemaHelpers.isUnbounded(type)){ >>>>>>>> //will map to array of primitive >>>>>>>> addReferencedPackage(PluginConstants >>>>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >>>>>>>> } else { >>>>>>>> //normal primtive like xsd:int >>>>>>>> } >>>>>>>> >>>>>>>> so the filtering never is considered. >>>>>>>> >>>>>>>> I will perform clean tests because was very difficult to find >>>>>>>> the real cause of the problem, the log file is not very clear >>>>>>>> in debug scenarios ( a lot of similar log text, no log from the >>>>>>>> templates and also cannot put the line number in the log file >>>>>>>> (tigerstripe issue)) and these problems have delayed my response. >>>>>>>> If the test go ok I will check out the changes to the trunk >>>>>>>> >>>>>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>>>>>> >>>>>>>> Best regards >>>>>>>> >>>>>>>> >>>>>>>> El 01/06/2012 16:58, Craig Gallen escribió: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I agree it is defined in internal_filter.xsd but it doesn't seem to be >>>>>>>>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >>>>>>>>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >>>>>>>>> shows an error. >>>>>>>>> >>>>>>>>> I think Xose is looking into it >>>>>>>>> >>>>>>>>> Craig >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Flauw, Marc [mailto:Mar...@hp...] >>>>>>>>> Sent: 01 June 2012 10:25 >>>>>>>>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >>>>>>>>> gauthier >>>>>>>>> Subject: RE: Problems with PM XSD generation >>>>>>>>> >>>>>>>>> Craig, >>>>>>>>> >>>>>>>>> There is one same filter in the getReosurceAlarms operation, filter >>>>>>>>> argument. >>>>>>>>> The XPathFilter is defined in the internal_filter.xsd >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> >>>>>>>>> Marc >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >>>>>>>>> Gallen (opennms) >>>>>>>>> Sent: Thursday, May 31, 2012 11:58 PM >>>>>>>>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >>>>>>>>> Subject: Problems with PM XSD generation >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I have been testing the TIP_PM_Col project model and have found that the >>>>>>>>> dep_cbe_perf_spec.xsd (attached) file is generated with errors >>>>>>>>> >>>>>>>>> in line 62 we have >>>>>>>>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >>>>>>>>> minOccurs="0" maxOccurs="1"> >>>>>>>>> >>>>>>>>> filter:XPathQueryFilter is not defined and if you open the file in eclipse >>>>>>>>> it reports this error as: >>>>>>>>> >>>>>>>>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >>>>>>>>> 'element'. Recorded reason: >>>>>>>>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >>>>>>>>> the prefix 'filter' is not >>>>>>>>> declared'. >>>>>>>>> >>>>>>>>> Is this a known problem or a new bug? >>>>>>>>> >>>>>>>>> Craig >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, >>>>>>>> Director I+D >>>>>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>>>>> www.optaresolutions.com >>>>>>>> <http://www.optaresolutions.com> >>>>>>>> Optare Solutions >>>>>>>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >>>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>>> www.optaresolutions.com >>>>>> <http://www.optaresolutions.com> >>>>>> Optare Solutions >>>>>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>>>>> >>>> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions >>>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>>> >>> >>> >> >> >> -- >> >> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions >> <http://optarecoolvendor.com><http://optarecoolvendor.com> >> > > |
|
From: Pierre G. <pga...@tm...> - 2012-06-28 04:57:12
|
All, I agree this should be fixed in Tigerstripe and we should NOT move to this new version until this and other related bugs of this new Tigerstripe version are identified and fixed. Pierre On Jun 28, 2012, at 12:32 AM, Craig Gallen (opennms) wrote: Xose & Marc, Is there a plan to complete primitive.url / primitive.uri in the soap generator. I have support for it in the Java generators but need the Soap generator working with this stereotype to test this code. Also has a bug been raised against Tigerstripe for the $allPackage issue ? I'd prefer to fix the problem in tigerstripe rather than have Xose get a work around because if this isnt working, its possible other 'get all collections' of artificates are not working. So this could be a general problem for the other generators including Cisco's own. Xose, have you raised a bug report and if so what is the bug number? Marc, when we have a bug report, can we escalate this directly to the tigerstripe team because it is a show stopper for us. I'm afraid I cannot do any more development until this is fixed. Thanks for your help Craig On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: I am going to test a workaround to see if this could be supported without change the tigerstripe core. Regards El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: Hi, So is there a work around or do we have to wait for Tigerstripe to sort this out. The old version of tigerstripe (6.9.xxx) is no longer available to download. Craig On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: Thanks Craig. I have performed some test and I can see an error in the Default Velocity context contents. When the $allPackage variable is used in the dependencyAnalyzer.vm template, it is expected that all artifacts, including the dependences, are included in that collection. In my tests I've got this behaivour: Old version of tigerstripe( Tigerstripe Core (Incubation) 0.6.935.201102010903 org.eclipse.tigerstripe.base.feature.group) %%%Calculate the dependencies/closure with [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), org.tmforum.tip.resource(240211633), org.tmforum.tip.cbe.perf(1039318676), org.tmforum.tip.common.notifications(23492680), org.tmforum.tip.resource.res(1133197283), org.tmforum.tip.cbe.root(1039387789), org.tmforum.tip(-660924437), org.tmforum.tip.cbe.root._char(-1449023596), org.tmforum(1644248382), org(110308), org.tmforum.tip.common(442435918), org.tmforum.tip.cbe.party(-2140978021), org.tmforum.tip.cbe.problem(292836116), org.tmforum.tip.cbe.root.tip.fmk(693071952), org.tmforum.tip.internal.filter(-1708340282), org.tmforum.tip.internal.extensibility(-1665414181), org.tmforum.tip.internal(1151687008), org.tmforum.tip.cbe.root.tip(1325885370), org.tmforum.tip.internal.notifications(-1680981798), org.tmforum.tip.common.exceptions(234099364), org.tmforum.tip.cbe.party.role(1514413545), org.tmforum.tip.internal.entity(-1732123599), org.tmforum.tip.resource.res.tip(-1716701168), org.tmforum.tip.internal.exceptions(-367434926), org.tmforum.tip.cbe(1681757027), org.tmforum.tip.internal.iterator(866200892), org.tmforum.tip.resource.res.tip.nrb(290014272)] [2012-06-26 10:21:29.996+0200] New version og tigerstripe( Tigerstripe Core (Incubation) 0.7.0.201206181258 org.eclipse.tigerstripe.base.feature.group): %%%Calculate the dependencies/closure with [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), org.tmforum.tip.resource(240211633)] [2012-06-26 10:28:54.989+0200] So it seems that this is root cause for the missed files. I will create a bug in Tigerstripe. Regards El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: Hi >From eclipse, Soap generator subversion; https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator Revision 3453 (last change revision 3444 last commit author xrsousa) Craig On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: Hi Craig, when you talk about the updated Soap Plugin, which version (in svn url) are using?, because the two first issues seems to be solved in the trunk with the other Tigerstripe version. Regards El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: Hi Xose, I just updated my tigerstripe to the latest release 0.7.0.20120618258 but Ialso updated the Soap plug-in and have found multiple problems but I am not sure if they are all related to the tigerstripe upgrade or to the current state of the soap plugin. Could you build the RAM project and check the generated XSD's to see the problem. 1. when you build the RAM project there is a problem with model closure. None of the Dependency XSD's get generated in the RAM_Model project 2. TrackingRecordResultWithIterator referenced as 'problem:TrackingRecordResultWithIterator' in ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd is never generated. 3. Tigerstripe 0.7.0.20120618258. handles primitive.string differently and generates type 'String' instead of 'java.lang.String' this results in type :String instead of xsd:string. I did a quick fix given in the following patch adding || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) to || "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) this means that old and new versions of tigerstipe will work There is a patch below but havent checked this in because I was not sure that else you were doing to the Soap plugin Craig ### Eclipse Workspace Patch 1.0 #P TIP_Soap_Generator Index: src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java =================================================================== --- src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java (revision 3453) +++ src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java (working copy) @@ -510,8 +510,8 @@ */ if (refType.isPrimitive() || refType.getPackage().equalsIgnoreCase("primitive") - || "java.lang.String".equalsIgnoreCase(refType - .getFullyQualifiedName())) { + || "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) + || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { // tigerstripe 1.7.0 now generates String and not java.lang.String PluginLog.logDebug("\'" + refTypeFullName + "\' is a primitive type in current TIP profile."); type = mapPrimitivesToXsdType(refType.getName(), isArray(refType), @@ -519,7 +519,7 @@ } /** - * Map datatyeps and enumerations + * Map datatypes and enumerations */ // if (refType.isDatatype() || refType.isEnum() else if (isDatatype(refType) || isEnumeration(refType)) { Index: src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java =================================================================== --- src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java (revision 3453) +++ src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java (working copy) @@ -170,8 +170,9 @@ private void addReferencedPackage(IType type) { if (type.isPrimitive() - || "primitive".equalsIgnoreCase(type.getPackage()) || - "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) { + || "primitive".equalsIgnoreCase(type.getPackage()) + || "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) + || "String".equalsIgnoreCase(type.getFullyQualifiedName())) { // tigerstripe 1.7.0 now generates String and not java.lang.String //will map objectName to EntityIdentifier or ArrayOfEntityIdentifier if ("objectName".equalsIgnoreCase(type.getName())){ PluginLog.logDebug("type \'" + type @@ -378,8 +379,8 @@ */ if (refType.isPrimitive() || refType.getPackage().equalsIgnoreCase("primitive") - || "java.lang.String".equalsIgnoreCase(refType - .getFullyQualifiedName())) { + || "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) + || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { // tigerstripe 1.7.0 now generates String and not java.lang.String PluginLog.logDebug("\'" + typeName + "\' is a primitive type in current TIP profile."); On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: Hi all. I think that I have found the error and I will try to fix it as soon as possible. There are some related issues, one error in the codification of a method and a forgetted evaluation of filtering in the velocity template and also a case related with primitive type filter not supported in the build of the closure outside the interfaces. In the interfaces build the search is performed as follows(this works fine as reported Marc): if ("objectName".equalsIgnoreCase(argType.getName())) { /* * This data type 'objectName' defines the protocol * neutral unique name of an object. This data type will * be replaced by the generators by an EntityIdentifier */ String pkg = PluginConstants .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); if (!this.map.containsKey(pkg)) { // // New package - add new pkg=prefix mapping // assignment // String prefix = XmlSchemaHelpers.generateXmlPrefix( pkg, this.map); this.map.put(pkg, prefix); } } else if ("filter".equalsIgnoreCase(argType.getName())) { /* * This data type 'filter'. This data type will * be replaced by the generator to */ String pkg = PluginConstants .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); if (!this.map.containsKey(pkg)) { // // New package - add new pkg=prefix mapping // assignment // String prefix = XmlSchemaHelpers.generateXmlPrefix( pkg, this.map); this.map.put(pkg, prefix); } } else if (XmlSchemaHelpers.isUnbounded(argType)) { String pkg = PluginConstants .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); if (!this.map.containsKey(pkg)) { // // New package - add new pkg=prefix mapping // assignment // String prefix = XmlSchemaHelpers.generateXmlPrefix( pkg, this.map); this.map.put(pkg, prefix); } } else { // XSD default namespace is enough } and in the build of the closure we have got (this fails as reported Craig): if ("objectName".equalsIgnoreCase(type.getName())){ PluginLog.logDebug("type \'" + type + "\' is an array of primitive."); addReferencedPackage(PluginConstants .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); }else if (XmlSchemaHelpers.isUnbounded(type)){ //will map to array of primitive addReferencedPackage(PluginConstants .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); } else { //normal primtive like xsd:int } so the filtering never is considered. I will perform clean tests because was very difficult to find the real cause of the problem, the log file is not very clear in debug scenarios ( a lot of similar log text, no log from the templates and also cannot put the line number in the log file (tigerstripe issue)) and these problems have delayed my response. If the test go ok I will check out the changes to the trunk https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator Best regards El 01/06/2012 16:58, Craig Gallen escribió: Hi, I agree it is defined in internal_filter.xsd but it doesn't seem to be referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also shows an error. I think Xose is looking into it Craig -----Original Message----- From: Flauw, Marc [mailto:Mar...@hp...] Sent: 01 June 2012 10:25 To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre gauthier Subject: RE: Problems with PM XSD generation Craig, There is one same filter in the getReosurceAlarms operation, filter argument. The XPathFilter is defined in the internal_filter.xsd Best regards Marc -----Original Message----- From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms) Sent: Thursday, May 31, 2012 11:58 PM To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier Subject: Problems with PM XSD generation Hi, I have been testing the TIP_PM_Col project model and have found that the dep_cbe_perf_spec.xsd (attached) file is generated with errors in line 62 we have <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" minOccurs="0" maxOccurs="1"> filter:XPathQueryFilter is not defined and if you open the file in eclipse it reports this error as: 's4s-att-invalid-value: Invalid attribute value for 'type' in element 'element'. Recorded reason: UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: the prefix 'filter' is not declared'. Is this a known problem or a new bug? Craig -- Xose Ramon Sousa Vazquez | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com/> <Mail Attachment.jpeg><http://optarecoolvendor.com/> <http://optarecoolvendor.com/> -- Xose Ramon Sousa Vazquez | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com/> <Mail Attachment.jpeg><http://optarecoolvendor.com/> <http://optarecoolvendor.com/> -- Xose Ramon Sousa Vazquez | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com/> <Mail Attachment.jpeg><http://optarecoolvendor.com/> <http://optarecoolvendor.com/> -- Xose Ramon Sousa Vazquez | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com/> <Mail Attachment.jpeg><http://optarecoolvendor.com/> <http://optarecoolvendor.com/> |
|
From: Flauw, M. <Mar...@hp...> - 2012-06-28 06:38:07
|
Pierre, We need Ft and Schedule for PM. There is no point in issuing a V1.1.2 if these features are not present. Best regards Marc From: Pierre Gauthier [mailto:pga...@tm...] Sent: Thursday, June 28, 2012 6:42 AM To: Craig Gallen (opennms) Cc: openoss-devel; Craig Gallen (entimoss); Xo...@do... Subject: Re: [Openoss-devel] Problems with PM XSD generation All, I agree this should be fixed in Tigerstripe and we should NOT move to this new version until this and other related bugs of this new Tigerstripe version are identified and fixed. Pierre On Jun 28, 2012, at 12:32 AM, Craig Gallen (opennms) wrote: Xose & Marc, Is there a plan to complete primitive.url / primitive.uri in the soap generator. I have support for it in the Java generators but need the Soap generator working with this stereotype to test this code. Also has a bug been raised against Tigerstripe for the $allPackage issue ? I'd prefer to fix the problem in tigerstripe rather than have Xose get a work around because if this isnt working, its possible other 'get all collections' of artificates are not working. So this could be a general problem for the other generators including Cisco's own. Xose, have you raised a bug report and if so what is the bug number? Marc, when we have a bug report, can we escalate this directly to the tigerstripe team because it is a show stopper for us. I'm afraid I cannot do any more development until this is fixed. Thanks for your help Craig On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: I am going to test a workaround to see if this could be supported without change the tigerstripe core. Regards El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: Hi, So is there a work around or do we have to wait for Tigerstripe to sort this out. The old version of tigerstripe (6.9.xxx) is no longer available to download. Craig On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: Thanks Craig. I have performed some test and I can see an error in the Default Velocity context contents. When the $allPackage variable is used in the dependencyAnalyzer.vm template, it is expected that all artifacts, including the dependences, are included in that collection. In my tests I've got this behaivour: Old version of tigerstripe( Tigerstripe Core (Incubation) 0.6.935.201102010903 org.eclipse.tigerstripe.base.feature.group) %%%Calculate the dependencies/closure with [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), org.tmforum.tip.resource(240211633), org.tmforum.tip.cbe.perf(1039318676), org.tmforum.tip.common.notifications(23492680), org.tmforum.tip.resource.res(1133197283), org.tmforum.tip.cbe.root(1039387789), org.tmforum.tip(-660924437), org.tmforum.tip.cbe.root._char(-1449023596), org.tmforum(1644248382), org(110308), org.tmforum.tip.common(442435918), org.tmforum.tip.cbe.party(-2140978021), org.tmforum.tip.cbe.problem(292836116), org.tmforum.tip.cbe.root.tip.fmk(693071952), org.tmforum.tip.internal.filter(-1708340282), org.tmforum.tip.internal.extensibility(-1665414181), org.tmforum.tip.internal(1151687008), org.tmforum.tip.cbe.root.tip(1325885370), org.tmforum.tip.internal.notifications(-1680981798), org.tmforum.tip.common.exceptions(234099364), org.tmforum.tip.cbe.party.role(1514413545), org.tmforum.tip.internal.entity(-1732123599), org.tmforum.tip.resource.res.tip(-1716701168), org.tmforum.tip.internal.exceptions(-367434926), org.tmforum.tip.cbe(1681757027), org.tmforum.tip.internal.iterator(866200892), org.tmforum.tip.resource.res.tip.nrb(290014272)] [2012-06-26 10:21:29.996+0200] New version og tigerstripe( Tigerstripe Core (Incubation) 0.7.0.201206181258 org.eclipse.tigerstripe.base.feature.group): %%%Calculate the dependencies/closure with [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), org.tmforum.tip.resource(240211633)] [2012-06-26 10:28:54.989+0200] So it seems that this is root cause for the missed files. I will create a bug in Tigerstripe. Regards El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: Hi >From eclipse, Soap generator subversion; https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator Revision 3453 (last change revision 3444 last commit author xrsousa) Craig On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: Hi Craig, when you talk about the updated Soap Plugin, which version (in svn url) are using?, because the two first issues seems to be solved in the trunk with the other Tigerstripe version. Regards El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: Hi Xose, I just updated my tigerstripe to the latest release 0.7.0.20120618258 but Ialso updated the Soap plug-in and have found multiple problems but I am not sure if they are all related to the tigerstripe upgrade or to the current state of the soap plugin. Could you build the RAM project and check the generated XSD's to see the problem. 1. when you build the RAM project there is a problem with model closure. None of the Dependency XSD's get generated in the RAM_Model project 2. TrackingRecordResultWithIterator referenced as 'problem:TrackingRecordResultWithIterator' in ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd is never generated. 3. Tigerstripe 0.7.0.20120618258. handles primitive.string differently and generates type 'String' instead of 'java.lang.String' this results in type :String instead of xsd:string. I did a quick fix given in the following patch adding || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) to || "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) this means that old and new versions of tigerstipe will work There is a patch below but havent checked this in because I was not sure that else you were doing to the Soap plugin Craig ### Eclipse Workspace Patch 1.0 #P TIP_Soap_Generator Index: src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java =================================================================== --- src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java (revision 3453) +++ src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java (working copy) @@ -510,8 +510,8 @@ */ if (refType.isPrimitive() || refType.getPackage().equalsIgnoreCase("primitive") - || "java.lang.String".equalsIgnoreCase(refType - .getFullyQualifiedName())) { + || "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) + || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { // tigerstripe 1.7.0 now generates String and not java.lang.String PluginLog.logDebug("\'" + refTypeFullName + "\' is a primitive type in current TIP profile."); type = mapPrimitivesToXsdType(refType.getName(), isArray(refType), @@ -519,7 +519,7 @@ } /** - * Map datatyeps and enumerations + * Map datatypes and enumerations */ // if (refType.isDatatype() || refType.isEnum() else if (isDatatype(refType) || isEnumeration(refType)) { Index: src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java =================================================================== --- src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java (revision 3453) +++ src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java (working copy) @@ -170,8 +170,9 @@ private void addReferencedPackage(IType type) { if (type.isPrimitive() - || "primitive".equalsIgnoreCase(type.getPackage()) || - "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) { + || "primitive".equalsIgnoreCase(type.getPackage()) + || "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) + || "String".equalsIgnoreCase(type.getFullyQualifiedName())) { // tigerstripe 1.7.0 now generates String and not java.lang.String //will map objectName to EntityIdentifier or ArrayOfEntityIdentifier if ("objectName".equalsIgnoreCase(type.getName())){ PluginLog.logDebug("type \'" + type @@ -378,8 +379,8 @@ */ if (refType.isPrimitive() || refType.getPackage().equalsIgnoreCase("primitive") - || "java.lang.String".equalsIgnoreCase(refType - .getFullyQualifiedName())) { + || "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) + || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { // tigerstripe 1.7.0 now generates String and not java.lang.String PluginLog.logDebug("\'" + typeName + "\' is a primitive type in current TIP profile."); On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: Hi all. I think that I have found the error and I will try to fix it as soon as possible. There are some related issues, one error in the codification of a method and a forgetted evaluation of filtering in the velocity template and also a case related with primitive type filter not supported in the build of the closure outside the interfaces. In the interfaces build the search is performed as follows(this works fine as reported Marc): if ("objectName".equalsIgnoreCase(argType.getName())) { /* * This data type 'objectName' defines the protocol * neutral unique name of an object. This data type will * be replaced by the generators by an EntityIdentifier */ String pkg = PluginConstants .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); if (!this.map.containsKey(pkg)) { // // New package - add new pkg=prefix mapping // assignment // String prefix = XmlSchemaHelpers.generateXmlPrefix( pkg, this.map); this.map.put(pkg, prefix); } } else if ("filter".equalsIgnoreCase(argType.getName())) { /* * This data type 'filter'. This data type will * be replaced by the generator to */ String pkg = PluginConstants .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); if (!this.map.containsKey(pkg)) { // // New package - add new pkg=prefix mapping // assignment // String prefix = XmlSchemaHelpers.generateXmlPrefix( pkg, this.map); this.map.put(pkg, prefix); } } else if (XmlSchemaHelpers.isUnbounded(argType)) { String pkg = PluginConstants .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); if (!this.map.containsKey(pkg)) { // // New package - add new pkg=prefix mapping // assignment // String prefix = XmlSchemaHelpers.generateXmlPrefix( pkg, this.map); this.map.put(pkg, prefix); } } else { // XSD default namespace is enough } and in the build of the closure we have got (this fails as reported Craig): if ("objectName".equalsIgnoreCase(type.getName())){ PluginLog.logDebug("type \'" + type + "\' is an array of primitive."); addReferencedPackage(PluginConstants .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); }else if (XmlSchemaHelpers.isUnbounded(type)){ //will map to array of primitive addReferencedPackage(PluginConstants .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); } else { //normal primtive like xsd:int } so the filtering never is considered. I will perform clean tests because was very difficult to find the real cause of the problem, the log file is not very clear in debug scenarios ( a lot of similar log text, no log from the templates and also cannot put the line number in the log file (tigerstripe issue)) and these problems have delayed my response. If the test go ok I will check out the changes to the trunk https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator Best regards El 01/06/2012 16:58, Craig Gallen escribió: Hi, I agree it is defined in internal_filter.xsd but it doesn't seem to be referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also shows an error. I think Xose is looking into it Craig -----Original Message----- From: Flauw, Marc [mailto:Mar...@hp...] Sent: 01 June 2012 10:25 To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre gauthier Subject: RE: Problems with PM XSD generation Craig, There is one same filter in the getReosurceAlarms operation, filter argument. The XPathFilter is defined in the internal_filter.xsd Best regards Marc -----Original Message----- From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms) Sent: Thursday, May 31, 2012 11:58 PM To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier Subject: Problems with PM XSD generation Hi, I have been testing the TIP_PM_Col project model and have found that the dep_cbe_perf_spec.xsd (attached) file is generated with errors in line 62 we have <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" minOccurs="0" maxOccurs="1"> filter:XPathQueryFilter is not defined and if you open the file in eclipse it reports this error as: 's4s-att-invalid-value: Invalid attribute value for 'type' in element 'element'. Recorded reason: UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: the prefix 'filter' is not declared'. Is this a known problem or a new bug? Craig -- Xose Ramon Sousa Vazquez | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com/> <Mail Attachment.jpeg><http://optarecoolvendor.com/> <http://optarecoolvendor.com/> -- Xose Ramon Sousa Vazquez | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com/> <Mail Attachment.jpeg><http://optarecoolvendor.com/> <http://optarecoolvendor.com/> -- Xose Ramon Sousa Vazquez | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com/> <Mail Attachment.jpeg><http://optarecoolvendor.com/> <http://optarecoolvendor.com/> -- Xose Ramon Sousa Vazquez | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com/> <Mail Attachment.jpeg><http://optarecoolvendor.com/> <http://optarecoolvendor.com/> |
|
From: Flauw, M. <Mar...@hp...> - 2012-06-28 06:20:53
|
Pierre, Our Tigerstripe version is dating back from Feb 2011. I simply announced that Tigerstripe is making a new version available for us so that we can test it. Before doing any regression tests, the minimum is first checking the generators are at least basically working and I think we are at this step now. We don't have structured regression tests yet. We have a serie of test projects, but not fully updated and operational. When using the installer, we have a stable version, both Tigerstripe and generators, but we need to reach a new one with the new Tigerstripe. Best regards Marc From: pierre gauthier [mailto:pie...@gm...] Sent: Thursday, June 28, 2012 6:27 AM To: Flauw, Marc Cc: Xose Ramon Sousa Vazquez; Craig Gallen (opennms); openoss-devel; Craig Gallen (entimoss) Subject: Re: Problems with PM XSD generation Hi Marc, Can you explain why we're moving to a new version of TigerStripe without having executed the proper regression tests ? Regards Pierre On Jun 28, 2012, at 12:17 AM, Craig Gallen (entimoss) wrote: Xose, Thanks for this. I am pretty much stuck until the fix can be made. I tried to go back to the previous tigerstripe version but this no longer works in my workspace. So I cant do anything more until either Tigerstripe or the the Soap generator are fixed. Craig On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: I am going to test a workaround to see if this could be supported without change the tigerstripe core. Regards El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: Hi, So is there a work around or do we have to wait for Tigerstripe to sort this out. The old version of tigerstripe (6.9.xxx) is no longer available to download. Craig On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: Thanks Craig. I have performed some test and I can see an error in the Default Velocity context contents. When the $allPackage variable is used in the dependencyAnalyzer.vm template, it is expected that all artifacts, including the dependences, are included in that collection. In my tests I've got this behaivour: Old version of tigerstripe( Tigerstripe Core (Incubation) 0.6.935.201102010903 org.eclipse.tigerstripe.base.feature.group) %%%Calculate the dependencies/closure with [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), org.tmforum.tip.resource(240211633), org.tmforum.tip.cbe.perf(1039318676), org.tmforum.tip.common.notifications(23492680), org.tmforum.tip.resource.res(1133197283), org.tmforum.tip.cbe.root(1039387789), org.tmforum.tip(-660924437), org.tmforum.tip.cbe.root._char(-1449023596), org.tmforum(1644248382), org(110308), org.tmforum.tip.common(442435918), org.tmforum.tip.cbe.party(-2140978021), org.tmforum.tip.cbe.problem(292836116), org.tmforum.tip.cbe.root.tip.fmk(693071952), org.tmforum.tip.internal.filter(-1708340282), org.tmforum.tip.internal.extensibility(-1665414181), org.tmforum.tip.internal(1151687008), org.tmforum.tip.cbe.root.tip(1325885370), org.tmforum.tip.internal.notifications(-1680981798), org.tmforum.tip.common.exceptions(234099364), org.tmforum.tip.cbe.party.role(1514413545), org.tmforum.tip.internal.entity(-1732123599), org.tmforum.tip.resource.res.tip(-1716701168), org.tmforum.tip.internal.exceptions(-367434926), org.tmforum.tip.cbe(1681757027), org.tmforum.tip.internal.iterator(866200892), org.tmforum.tip.resource.res.tip.nrb(290014272)] [2012-06-26 10:21:29.996+0200] New version og tigerstripe( Tigerstripe Core (Incubation) 0.7.0.201206181258 org.eclipse.tigerstripe.base.feature.group): %%%Calculate the dependencies/closure with [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), org.tmforum.tip.resource(240211633)] [2012-06-26 10:28:54.989+0200] So it seems that this is root cause for the missed files. I will create a bug in Tigerstripe. Regards El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: Hi >From eclipse, Soap generator subversion; https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator Revision 3453 (last change revision 3444 last commit author xrsousa) Craig On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: Hi Craig, when you talk about the updated Soap Plugin, which version (in svn url) are using?, because the two first issues seems to be solved in the trunk with the other Tigerstripe version. Regards El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: Hi Xose, I just updated my tigerstripe to the latest release 0.7.0.20120618258 but Ialso updated the Soap plug-in and have found multiple problems but I am not sure if they are all related to the tigerstripe upgrade or to the current state of the soap plugin. Could you build the RAM project and check the generated XSD's to see the problem. 1. when you build the RAM project there is a problem with model closure. None of the Dependency XSD's get generated in the RAM_Model project 2. TrackingRecordResultWithIterator referenced as 'problem:TrackingRecordResultWithIterator' in ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd is never generated. 3. Tigerstripe 0.7.0.20120618258. handles primitive.string differently and generates type 'String' instead of 'java.lang.String' this results in type :String instead of xsd:string. I did a quick fix given in the following patch adding || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) to || "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) this means that old and new versions of tigerstipe will work There is a patch below but havent checked this in because I was not sure that else you were doing to the Soap plugin Craig ### Eclipse Workspace Patch 1.0 #P TIP_Soap_Generator Index: src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java =================================================================== --- src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java (revision 3453) +++ src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java (working copy) @@ -510,8 +510,8 @@ */ if (refType.isPrimitive() || refType.getPackage().equalsIgnoreCase("primitive") - || "java.lang.String".equalsIgnoreCase(refType - .getFullyQualifiedName())) { + || "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) + || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { // tigerstripe 1.7.0 now generates String and not java.lang.String PluginLog.logDebug("\'" + refTypeFullName + "\' is a primitive type in current TIP profile."); type = mapPrimitivesToXsdType(refType.getName(), isArray(refType), @@ -519,7 +519,7 @@ } /** - * Map datatyeps and enumerations + * Map datatypes and enumerations */ // if (refType.isDatatype() || refType.isEnum() else if (isDatatype(refType) || isEnumeration(refType)) { Index: src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java =================================================================== --- src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java (revision 3453) +++ src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java (working copy) @@ -170,8 +170,9 @@ private void addReferencedPackage(IType type) { if (type.isPrimitive() - || "primitive".equalsIgnoreCase(type.getPackage()) || - "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) { + || "primitive".equalsIgnoreCase(type.getPackage()) + || "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) + || "String".equalsIgnoreCase(type.getFullyQualifiedName())) { // tigerstripe 1.7.0 now generates String and not java.lang.String //will map objectName to EntityIdentifier or ArrayOfEntityIdentifier if ("objectName".equalsIgnoreCase(type.getName())){ PluginLog.logDebug("type \'" + type @@ -378,8 +379,8 @@ */ if (refType.isPrimitive() || refType.getPackage().equalsIgnoreCase("primitive") - || "java.lang.String".equalsIgnoreCase(refType - .getFullyQualifiedName())) { + || "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) + || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { // tigerstripe 1.7.0 now generates String and not java.lang.String PluginLog.logDebug("\'" + typeName + "\' is a primitive type in current TIP profile."); On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: Hi all. I think that I have found the error and I will try to fix it as soon as possible. There are some related issues, one error in the codification of a method and a forgetted evaluation of filtering in the velocity template and also a case related with primitive type filter not supported in the build of the closure outside the interfaces. In the interfaces build the search is performed as follows(this works fine as reported Marc): if ("objectName".equalsIgnoreCase(argType.getName())) { /* * This data type 'objectName' defines the protocol * neutral unique name of an object. This data type will * be replaced by the generators by an EntityIdentifier */ String pkg = PluginConstants .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); if (!this.map.containsKey(pkg)) { // // New package - add new pkg=prefix mapping // assignment // String prefix = XmlSchemaHelpers.generateXmlPrefix( pkg, this.map); this.map.put(pkg, prefix); } } else if ("filter".equalsIgnoreCase(argType.getName())) { /* * This data type 'filter'. This data type will * be replaced by the generator to */ String pkg = PluginConstants .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); if (!this.map.containsKey(pkg)) { // // New package - add new pkg=prefix mapping // assignment // String prefix = XmlSchemaHelpers.generateXmlPrefix( pkg, this.map); this.map.put(pkg, prefix); } } else if (XmlSchemaHelpers.isUnbounded(argType)) { String pkg = PluginConstants .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); if (!this.map.containsKey(pkg)) { // // New package - add new pkg=prefix mapping // assignment // String prefix = XmlSchemaHelpers.generateXmlPrefix( pkg, this.map); this.map.put(pkg, prefix); } } else { // XSD default namespace is enough } and in the build of the closure we have got (this fails as reported Craig): if ("objectName".equalsIgnoreCase(type.getName())){ PluginLog.logDebug("type \'" + type + "\' is an array of primitive."); addReferencedPackage(PluginConstants .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); }else if (XmlSchemaHelpers.isUnbounded(type)){ //will map to array of primitive addReferencedPackage(PluginConstants .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); } else { //normal primtive like xsd:int } so the filtering never is considered. I will perform clean tests because was very difficult to find the real cause of the problem, the log file is not very clear in debug scenarios ( a lot of similar log text, no log from the templates and also cannot put the line number in the log file (tigerstripe issue)) and these problems have delayed my response. If the test go ok I will check out the changes to the trunk https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator Best regards El 01/06/2012 16:58, Craig Gallen escribió: Hi, I agree it is defined in internal_filter.xsd but it doesn't seem to be referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also shows an error. I think Xose is looking into it Craig -----Original Message----- From: Flauw, Marc [mailto:Mar...@hp...] Sent: 01 June 2012 10:25 To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre gauthier Subject: RE: Problems with PM XSD generation Craig, There is one same filter in the getReosurceAlarms operation, filter argument. The XPathFilter is defined in the internal_filter.xsd Best regards Marc -----Original Message----- From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms) Sent: Thursday, May 31, 2012 11:58 PM To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier Subject: Problems with PM XSD generation Hi, I have been testing the TIP_PM_Col project model and have found that the dep_cbe_perf_spec.xsd (attached) file is generated with errors in line 62 we have <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" minOccurs="0" maxOccurs="1"> filter:XPathQueryFilter is not defined and if you open the file in eclipse it reports this error as: 's4s-att-invalid-value: Invalid attribute value for 'type' in element 'element'. Recorded reason: UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: the prefix 'filter' is not declared'. Is this a known problem or a new bug? Craig -- Xose Ramon Sousa Vazquez | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com/> <Mail Attachment.jpeg><http://optarecoolvendor.com/> <http://optarecoolvendor.com/> -- Xose Ramon Sousa Vazquez | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com/> <Mail Attachment.jpeg><http://optarecoolvendor.com/> <http://optarecoolvendor.com/> -- Xose Ramon Sousa Vazquez | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com/> <Mail Attachment.jpeg><http://optarecoolvendor.com/> <http://optarecoolvendor.com/> -- Xose Ramon Sousa Vazquez | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com/> <Mail Attachment.jpeg><http://optarecoolvendor.com/> <http://optarecoolvendor.com/> |
|
From: Xose R. S. V. <xr...@op...> - 2012-06-28 07:17:56
|
Hi all. I have post the problem in the user list as the bug creation recommends. Nobody answer that so I am going to create the bug. I have a first version of the workaround but aome problems are derived in the cast operations in the src_shared classes, so I must investigate deeper. If this issue is solved I can send you Craig a preeliminary patch and then check the behaivour of the other $allxxxx context elements. Regards El 28/06/2012 6:32, Craig Gallen (opennms) escribió: > Xose & Marc, > > Is there a plan to complete primitive.url / primitive.uri in the soap > generator. I have support for it in the Java generators but need the > Soap generator working with this stereotype to test this code. > > Also has a bug been raised against Tigerstripe for the $allPackage > issue ? I'd prefer to fix the problem in tigerstripe rather than have > Xose get a work around because if this isnt working, its possible > other 'get all collections' of artificates are not working. So this > could be a general problem for the other generators including Cisco's own. > > Xose, have you raised a bug report and if so what is the bug number? > > Marc, when we have a bug report, can we escalate this directly to the > tigerstripe team because it is a show stopper for us. > > I'm afraid I cannot do any more development until this is fixed. > > Thanks for your help > > Craig > > > >> >> >> >> On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: >>> I am going to test a workaround to see if this could be supported >>> without change the tigerstripe core. >>> >>> Regards >>> El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: >>>> Hi, >>>> >>>> So is there a work around or do we have to wait for Tigerstripe to >>>> sort this out. >>>> The old version of tigerstripe (6.9.xxx) is no longer available to >>>> download. >>>> >>>> Craig >>>> >>>> >>>> On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >>>>> Thanks Craig. >>>>> I have performed some test and I can see an error in the Default >>>>> Velocity context contents. When the $allPackage variable is used >>>>> in the dependencyAnalyzer.vm template, it is expected that all >>>>> artifacts, including the dependences, are included in that >>>>> collection. In my tests I've got this behaivour: >>>>> >>>>> Old version of tigerstripe( Tigerstripe Core (Incubation) >>>>> 0.6.935.201102010903 org.eclipse.tigerstripe.base.feature.group) >>>>> %%%Calculate the dependencies/closure with >>>>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>>>> org.tmforum.tip.resource.trouble(428889018), >>>>> org.tmforum.tip.resource(240211633), >>>>> org.tmforum.tip.cbe.perf(1039318676), >>>>> org.tmforum.tip.common.notifications(23492680), >>>>> org.tmforum.tip.resource.res(1133197283), >>>>> org.tmforum.tip.cbe.root(1039387789), org.tmforum.tip(-660924437), >>>>> org.tmforum.tip.cbe.root._char(-1449023596), >>>>> org.tmforum(1644248382), org(110308), >>>>> org.tmforum.tip.common(442435918), >>>>> org.tmforum.tip.cbe.party(-2140978021), >>>>> org.tmforum.tip.cbe.problem(292836116), >>>>> org.tmforum.tip.cbe.root.tip.fmk(693071952), >>>>> org.tmforum.tip.internal.filter(-1708340282), >>>>> org.tmforum.tip.internal.extensibility(-1665414181), >>>>> org.tmforum.tip.internal(1151687008), >>>>> org.tmforum.tip.cbe.root.tip(1325885370), >>>>> org.tmforum.tip.internal.notifications(-1680981798), >>>>> org.tmforum.tip.common.exceptions(234099364), >>>>> org.tmforum.tip.cbe.party.role(1514413545), >>>>> org.tmforum.tip.internal.entity(-1732123599), >>>>> org.tmforum.tip.resource.res.tip(-1716701168), >>>>> org.tmforum.tip.internal.exceptions(-367434926), >>>>> org.tmforum.tip.cbe(1681757027), >>>>> org.tmforum.tip.internal.iterator(866200892), >>>>> org.tmforum.tip.resource.res.tip.nrb(290014272)] [2012-06-26 >>>>> 10:21:29.996+0200] >>>>> >>>>> New version og tigerstripe( Tigerstripe Core (Incubation) >>>>> 0.7.0.201206181258 org.eclipse.tigerstripe.base.feature.group): >>>>> %%%Calculate the dependencies/closure with >>>>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>>>> org.tmforum.tip.resource.trouble(428889018), >>>>> org.tmforum.tip.resource(240211633)] [2012-06-26 10:28:54.989+0200] >>>>> >>>>> So it seems that this is root cause for the missed files. >>>>> I will create a bug in Tigerstripe. >>>>> >>>>> Regards >>>>> >>>>> El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: >>>>>> Hi >>>>>> From eclipse, Soap generator subversion; >>>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>>>> Revision 3453 >>>>>> (last change revision 3444 last commit author xrsousa) >>>>>> >>>>>> Craig >>>>>> >>>>>> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >>>>>>> Hi Craig, when you talk about the updated Soap Plugin, which >>>>>>> version (in svn url) are using?, because the two first issues >>>>>>> seems to be solved in the trunk with the other Tigerstripe version. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards >>>>>>> El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: >>>>>>>> Hi Xose, >>>>>>>> >>>>>>>> I just updated my tigerstripe to the latest release >>>>>>>> 0.7.0.20120618258 but Ialso updated the Soap plug-in and have >>>>>>>> found multiple problems but I am not sure if they are all >>>>>>>> related to the tigerstripe upgrade or to the current state of >>>>>>>> the soap plugin. Could you build the RAM project and check the >>>>>>>> generated XSD's to see the problem. >>>>>>>> >>>>>>>> 1. when you build the RAM project there is a problem with model >>>>>>>> closure. None of the Dependency XSD's get generated in the >>>>>>>> RAM_Model project >>>>>>>> >>>>>>>> 2. TrackingRecordResultWithIterator referenced as >>>>>>>> 'problem:TrackingRecordResultWithIterator' in >>>>>>>> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd is >>>>>>>> never generated. >>>>>>>> >>>>>>>> 3. Tigerstripe 0.7.0.20120618258. handles primitive.string >>>>>>>> differently and generates type 'String' instead of >>>>>>>> 'java.lang.String' this results in type :String instead of >>>>>>>> xsd:string. I did a quick fix given in the following patch adding >>>>>>>> || "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>>>>> >>>>>>>> to >>>>>>>> || >>>>>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>>>>> this means that old and new versions of tigerstipe will work >>>>>>>> >>>>>>>> There is a patch below but havent checked this in because I >>>>>>>> was not sure that else you were doing to the Soap plugin >>>>>>>> >>>>>>>> Craig >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ### Eclipse Workspace Patch 1.0 >>>>>>>> #P TIP_Soap_Generator >>>>>>>> Index: >>>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>>>>> =================================================================== >>>>>>>> --- >>>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>>>>> (revision 3453) >>>>>>>> +++ >>>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>>>>> (working copy) >>>>>>>> @@ -510,8 +510,8 @@ >>>>>>>> */ >>>>>>>> if (refType.isPrimitive() >>>>>>>> || >>>>>>>> refType.getPackage().equalsIgnoreCase("primitive") >>>>>>>> - || "java.lang.String".equalsIgnoreCase(refType >>>>>>>> - .getFullyQualifiedName())) { >>>>>>>> + || >>>>>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>>>>> + || >>>>>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { >>>>>>>> // tigerstripe 1.7.0 now generates String and not java.lang.String >>>>>>>> PluginLog.logDebug("\'" + refTypeFullName >>>>>>>> + "\' is a primitive type in current TIP >>>>>>>> profile."); >>>>>>>> type = mapPrimitivesToXsdType(refType.getName(), >>>>>>>> isArray(refType), >>>>>>>> @@ -519,7 +519,7 @@ >>>>>>>> } >>>>>>>> >>>>>>>> /** >>>>>>>> - * Map datatyeps and enumerations >>>>>>>> + * Map datatypes and enumerations >>>>>>>> */ >>>>>>>> // if (refType.isDatatype() || refType.isEnum() >>>>>>>> else if (isDatatype(refType) || isEnumeration(refType)) { >>>>>>>> Index: >>>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>>>>> =================================================================== >>>>>>>> --- >>>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>>>>> (revision 3453) >>>>>>>> +++ >>>>>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>>>>> (working copy) >>>>>>>> @@ -170,8 +170,9 @@ >>>>>>>> private void addReferencedPackage(IType type) { >>>>>>>> >>>>>>>> if (type.isPrimitive() >>>>>>>> - || >>>>>>>> "primitive".equalsIgnoreCase(type.getPackage()) || >>>>>>>> - >>>>>>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) >>>>>>>> { >>>>>>>> + || "primitive".equalsIgnoreCase(type.getPackage()) >>>>>>>> + || >>>>>>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>>>>>>> + || >>>>>>>> "String".equalsIgnoreCase(type.getFullyQualifiedName())) { // >>>>>>>> tigerstripe 1.7.0 now generates String and not java.lang.String >>>>>>>> //will map objectName to EntityIdentifier or >>>>>>>> ArrayOfEntityIdentifier >>>>>>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>>>>>> PluginLog.logDebug("type \'" + type >>>>>>>> @@ -378,8 +379,8 @@ >>>>>>>> */ >>>>>>>> if (refType.isPrimitive() >>>>>>>> || >>>>>>>> refType.getPackage().equalsIgnoreCase("primitive") >>>>>>>> - || "java.lang.String".equalsIgnoreCase(refType >>>>>>>> - .getFullyQualifiedName())) { >>>>>>>> + || >>>>>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>>>>> + || >>>>>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) { >>>>>>>> // tigerstripe 1.7.0 now generates String and not java.lang.String >>>>>>>> PluginLog.logDebug("\'" + typeName >>>>>>>> + "\' is a primitive type in current TIP >>>>>>>> profile."); >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>>>>>>>> Hi all. I think that I have found the error and I will try to >>>>>>>>> fix it as soon as possible. There are some related issues, one >>>>>>>>> error in the codification of a method and a forgetted >>>>>>>>> evaluation of filtering in the velocity template and also a >>>>>>>>> case related with primitive type filter not supported in the >>>>>>>>> build of the closure outside the interfaces. >>>>>>>>> >>>>>>>>> In the interfaces build the search is performed as >>>>>>>>> follows(this works fine as reported Marc): >>>>>>>>> >>>>>>>>> if >>>>>>>>> ("objectName".equalsIgnoreCase(argType.getName())) { >>>>>>>>> /* >>>>>>>>> * This data type 'objectName' >>>>>>>>> defines the protocol >>>>>>>>> * neutral unique name of an >>>>>>>>> object. This data type will >>>>>>>>> * be replaced by the generators >>>>>>>>> by an EntityIdentifier >>>>>>>>> */ >>>>>>>>> String pkg = PluginConstants >>>>>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>>>>>>>> if (!this.map.containsKey(pkg)) { >>>>>>>>> // >>>>>>>>> // New package - add new >>>>>>>>> pkg=prefix mapping >>>>>>>>> // assignment >>>>>>>>> // >>>>>>>>> String prefix = >>>>>>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>>>>>> pkg, this.map); >>>>>>>>> this.map.put(pkg, prefix); >>>>>>>>> } >>>>>>>>> } else if >>>>>>>>> ("filter".equalsIgnoreCase(argType.getName())) { >>>>>>>>> /* >>>>>>>>> * This data type 'filter'. This >>>>>>>>> data type will >>>>>>>>> * be replaced by the generator to >>>>>>>>> */ >>>>>>>>> String pkg = PluginConstants >>>>>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >>>>>>>>> if (!this.map.containsKey(pkg)) { >>>>>>>>> // >>>>>>>>> // New package - add new >>>>>>>>> pkg=prefix mapping >>>>>>>>> // assignment >>>>>>>>> // >>>>>>>>> String prefix = >>>>>>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>>>>>> pkg, this.map); >>>>>>>>> this.map.put(pkg, prefix); >>>>>>>>> } >>>>>>>>> } else if >>>>>>>>> (XmlSchemaHelpers.isUnbounded(argType)) { >>>>>>>>> String pkg = PluginConstants >>>>>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >>>>>>>>> if (!this.map.containsKey(pkg)) { >>>>>>>>> // >>>>>>>>> // New package - add new >>>>>>>>> pkg=prefix mapping >>>>>>>>> // assignment >>>>>>>>> // >>>>>>>>> String prefix = >>>>>>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>>>>>> pkg, this.map); >>>>>>>>> this.map.put(pkg, prefix); >>>>>>>>> } >>>>>>>>> } else { >>>>>>>>> // XSD default namespace is enough >>>>>>>>> } >>>>>>>>> >>>>>>>>> and in the build of the closure we have got (this fails as >>>>>>>>> reported Craig): >>>>>>>>> >>>>>>>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>>>>>>> PluginLog.logDebug("type \'" + type >>>>>>>>> + "\' is an array of primitive."); >>>>>>>>> addReferencedPackage(PluginConstants >>>>>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >>>>>>>>> }else if (XmlSchemaHelpers.isUnbounded(type)){ >>>>>>>>> //will map to array of primitive >>>>>>>>> addReferencedPackage(PluginConstants >>>>>>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >>>>>>>>> } else { >>>>>>>>> //normal primtive like xsd:int >>>>>>>>> } >>>>>>>>> >>>>>>>>> so the filtering never is considered. >>>>>>>>> >>>>>>>>> I will perform clean tests because was very difficult to find >>>>>>>>> the real cause of the problem, the log file is not very clear >>>>>>>>> in debug scenarios ( a lot of similar log text, no log from >>>>>>>>> the templates and also cannot put the line number in the log >>>>>>>>> file (tigerstripe issue)) and these problems have delayed my >>>>>>>>> response. >>>>>>>>> If the test go ok I will check out the changes to the trunk >>>>>>>>> >>>>>>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> >>>>>>>>> >>>>>>>>> El 01/06/2012 16:58, Craig Gallen escribió: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I agree it is defined in internal_filter.xsd but it doesn't seem to be >>>>>>>>>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >>>>>>>>>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >>>>>>>>>> shows an error. >>>>>>>>>> >>>>>>>>>> I think Xose is looking into it >>>>>>>>>> >>>>>>>>>> Craig >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Flauw, Marc [mailto:Mar...@hp...] >>>>>>>>>> Sent: 01 June 2012 10:25 >>>>>>>>>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >>>>>>>>>> gauthier >>>>>>>>>> Subject: RE: Problems with PM XSD generation >>>>>>>>>> >>>>>>>>>> Craig, >>>>>>>>>> >>>>>>>>>> There is one same filter in the getReosurceAlarms operation, filter >>>>>>>>>> argument. >>>>>>>>>> The XPathFilter is defined in the internal_filter.xsd >>>>>>>>>> >>>>>>>>>> Best regards >>>>>>>>>> >>>>>>>>>> Marc >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >>>>>>>>>> Gallen (opennms) >>>>>>>>>> Sent: Thursday, May 31, 2012 11:58 PM >>>>>>>>>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >>>>>>>>>> Subject: Problems with PM XSD generation >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I have been testing the TIP_PM_Col project model and have found that the >>>>>>>>>> dep_cbe_perf_spec.xsd (attached) file is generated with errors >>>>>>>>>> >>>>>>>>>> in line 62 we have >>>>>>>>>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >>>>>>>>>> minOccurs="0" maxOccurs="1"> >>>>>>>>>> >>>>>>>>>> filter:XPathQueryFilter is not defined and if you open the file in eclipse >>>>>>>>>> it reports this error as: >>>>>>>>>> >>>>>>>>>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >>>>>>>>>> 'element'. Recorded reason: >>>>>>>>>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >>>>>>>>>> the prefix 'filter' is not >>>>>>>>>> declared'. >>>>>>>>>> >>>>>>>>>> Is this a known problem or a new bug? >>>>>>>>>> >>>>>>>>>> Craig >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, >>>>>>>>> Director I+D >>>>>>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>>>>>> www.optaresolutions.com >>>>>>>>> <http://www.optaresolutions.com> >>>>>>>>> Optare Solutions >>>>>>>>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >>>>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>>>> www.optaresolutions.com >>>>>>> <http://www.optaresolutions.com> >>>>>>> Optare Solutions >>>>>>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions >>>>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>>>> >>>> >>>> >>> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions >>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>> >> >> > > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Xose R. S. V. <xr...@op...> - 2012-06-28 07:44:48
|
I have created the bug Bug 383728 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>has been added to the database Email sent to: |dke...@ci...|,|erd...@ci...|,|tig...@ec...|,|jis...@ci...|,|rcr...@ci...| Excluding: |xr...@op...| Regards El 28/06/2012 9:18, Flauw, Marc escribió: > > Xose, > > Send us the bug pointer and I will escalate it . > > Best regards > > Marc > > *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] > *Sent:* Thursday, June 28, 2012 9:17 AM > *To:* Craig Gallen (opennms) > *Cc:* 'openoss-devel'; Craig Gallen (entimoss); 'pierre gauthier' > *Subject:* Re: [Openoss-devel] Problems with PM XSD generation > > Hi all. > I have post the problem in the user list as the bug creation > recommends. Nobody answer that so I am going to create the bug. I have > a first version of the workaround but aome problems are derived in the > cast operations in the src_shared classes, so I must investigate > deeper. If this issue is solved I can send you Craig a preeliminary > patch and then check the behaivour of the other $allxxxx context elements. > > > Regards > El 28/06/2012 6:32, Craig Gallen (opennms) escribió: > > Xose & Marc, > > Is there a plan to complete primitive.url / primitive.uri in the > soap generator. I have support for it in the Java generators but > need the Soap generator working with this stereotype to test this > code. > > Also has a bug been raised against Tigerstripe for the $allPackage > issue ? I'd prefer to fix the problem in tigerstripe rather than > have Xose get a work around because if this isnt working, its > possible other 'get all collections' of artificates are not > working. So this could be a general problem for the other > generators including Cisco's own. > > Xose, have you raised a bug report and if so what is the bug number? > > Marc, when we have a bug report, can we escalate this directly to > the tigerstripe team because it is a show stopper for us. > > I'm afraid I cannot do any more development until this is fixed. > > Thanks for your help > > Craig > > > > > > > On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: > > I am going to test a workaround to see if this could be > supported without change the tigerstripe core. > > Regards > El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: > > Hi, > > So is there a work around or do we have to wait for > Tigerstripe to sort this out. > The old version of tigerstripe (6.9.xxx) is no longer > available to download. > > Craig > > On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: > > Thanks Craig. > I have performed some test and I can see an error in > the Default Velocity context contents. When the > $allPackage variable is used in the > dependencyAnalyzer.vm template, it is expected that > all artifacts, including the dependences, are included > in that collection. In my tests I've got this behaivour: > > Old version of tigerstripe( Tigerstripe Core > (Incubation) 0.6.935.201102010903 > org.eclipse.tigerstripe.base.feature.group) > %%%Calculate the dependencies/closure with > [org.tmforum.tip.resource.trouble.alarm(370509597), > org.tmforum.tip.resource.trouble(428889018), > org.tmforum.tip.resource(240211633), > org.tmforum.tip.cbe.perf(1039318676), > org.tmforum.tip.common.notifications(23492680), > org.tmforum.tip.resource.res(1133197283), > org.tmforum.tip.cbe.root(1039387789), > org.tmforum.tip(-660924437), > org.tmforum.tip.cbe.root._char(-1449023596), > org.tmforum(1644248382), org(110308), > org.tmforum.tip.common(442435918), > org.tmforum.tip.cbe.party(-2140978021), > org.tmforum.tip.cbe.problem(292836116), > org.tmforum.tip.cbe.root.tip.fmk(693071952), > org.tmforum.tip.internal.filter(-1708340282), > org.tmforum.tip.internal.extensibility(-1665414181), > org.tmforum.tip.internal(1151687008), > org.tmforum.tip.cbe.root.tip(1325885370), > org.tmforum.tip.internal.notifications(-1680981798), > org.tmforum.tip.common.exceptions(234099364), > org.tmforum.tip.cbe.party.role(1514413545), > org.tmforum.tip.internal.entity(-1732123599), > org.tmforum.tip.resource.res.tip(-1716701168), > org.tmforum.tip.internal.exceptions(-367434926), > org.tmforum.tip.cbe(1681757027), > org.tmforum.tip.internal.iterator(866200892), > org.tmforum.tip.resource.res.tip.nrb(290014272)] > [2012-06-26 10:21:29.996+0200] > > New version og tigerstripe( Tigerstripe Core > (Incubation) 0.7.0.201206181258 > org.eclipse.tigerstripe.base.feature.group): > %%%Calculate the dependencies/closure with > [org.tmforum.tip.resource.trouble.alarm(370509597), > org.tmforum.tip.resource.trouble(428889018), > org.tmforum.tip.resource(240211633)] [2012-06-26 > 10:28:54.989+0200] > > So it seems that this is root cause for the missed files. > I will create a bug in Tigerstripe. > > Regards > > El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: > > Hi > From eclipse, Soap generator subversion; > https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator > Revision 3453 > (last change revision 3444 last commit author xrsousa) > > Craig > > On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: > > Hi Craig, when you talk about the updated Soap Plugin, > which version (in svn url) are using?, because the two > first issues seems to be solved in the trunk with the > other Tigerstripe version. > > > > > Regards > El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: > > Hi Xose, > > I just updated my tigerstripe to the latest release > 0.7.0.20120618258 but Ialso updated the Soap plug-in > and have found multiple problems but I am not sure if > they are all related to the tigerstripe upgrade or to > the current state of the soap plugin. Could you build > the RAM project and check the generated XSD's to see > the problem. > > 1. when you build the RAM project there is a problem > with model closure. None of the Dependency XSD's get > generated in the RAM_Model project > > 2. TrackingRecordResultWithIterator referenced as > 'problem:TrackingRecordResultWithIterator' in > ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd > is never generated. > > 3. Tigerstripe 0.7.0.20120618258. handles > primitive.string differently and generates type > 'String' instead of 'java.lang.String' this results in > type :String instead of xsd:string. I did a quick fix > given in the following patch adding > || > "String".equalsIgnoreCase(refType.getFullyQualifiedName())) > > to > || > "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) > this means that old and new versions of tigerstipe > will work > > There is a patch below but havent checked this in > because I was not sure that else you were doing to the > Soap plugin > > Craig > > > > ### Eclipse Workspace Patch 1.0 > #P TIP_Soap_Generator > Index: > src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java > =================================================================== > --- > src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java > (revision 3453) > +++ > src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java > (working copy) > @@ -510,8 +510,8 @@ > */ > if (refType.isPrimitive() > || > refType.getPackage().equalsIgnoreCase("primitive") > - || > "java.lang.String".equalsIgnoreCase(refType > - .getFullyQualifiedName())) { > + || > "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) > + || > "String".equalsIgnoreCase(refType.getFullyQualifiedName())) > { // tigerstripe 1.7.0 now generates String and not > java.lang.String > PluginLog.logDebug("\'" + refTypeFullName > + "\' is a primitive type in > current TIP profile."); > type = > mapPrimitivesToXsdType(refType.getName(), > isArray(refType), > @@ -519,7 +519,7 @@ > } > > /** > - * Map datatyeps and enumerations > + * Map datatypes and enumerations > */ > // if (refType.isDatatype() || refType.isEnum() > else if (isDatatype(refType) || > isEnumeration(refType)) { > Index: > src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java > =================================================================== > --- > src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java > (revision 3453) > +++ > src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java > (working copy) > @@ -170,8 +170,9 @@ > private void addReferencedPackage(IType type) { > > if (type.isPrimitive() > - || > "primitive".equalsIgnoreCase(type.getPackage()) || > - > "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) > { > + || > "primitive".equalsIgnoreCase(type.getPackage()) > + || > "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) > + || > "String".equalsIgnoreCase(type.getFullyQualifiedName())) > { // tigerstripe 1.7.0 now generates String and not > java.lang.String > //will map objectName to EntityIdentifier > or ArrayOfEntityIdentifier > if > ("objectName".equalsIgnoreCase(type.getName())){ > PluginLog.logDebug("type \'" + type > @@ -378,8 +379,8 @@ > */ > if (refType.isPrimitive() > || > refType.getPackage().equalsIgnoreCase("primitive") > - || > "java.lang.String".equalsIgnoreCase(refType > - .getFullyQualifiedName())) { > + || > "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) > + || > "String".equalsIgnoreCase(refType.getFullyQualifiedName())) > { // tigerstripe 1.7.0 now generates String and not > java.lang.String > PluginLog.logDebug("\'" + typeName > + "\' is a primitive type in > current TIP profile."); > > > > > > > > On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: > > Hi all. I think that I have found the error and I will > try to fix it as soon as possible. There are some > related issues, one error in the codification of a > method and a forgetted evaluation of filtering in the > velocity template and also a case related with > primitive type filter not supported in the build of > the closure outside the interfaces. > > In the interfaces build the search is performed as > follows(this works fine as reported Marc): > > if > ("objectName".equalsIgnoreCase(argType.getName())) { > /* > * This data type 'objectName' > defines the protocol > * neutral unique name of an > object. This data type will > * be replaced by the > generators by an EntityIdentifier > */ > String pkg = PluginConstants > .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); > if (!this.map.containsKey(pkg)) { > // > // New package - add new > pkg=prefix mapping > // assignment > // > String prefix = > XmlSchemaHelpers.generateXmlPrefix( > pkg, this.map); > this.map.put(pkg, prefix); > } > } else if > ("filter".equalsIgnoreCase(argType.getName())) { > /* > * This data type 'filter'. > This data type will > * be replaced by the generator to > */ > String pkg = PluginConstants > .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); > if (!this.map.containsKey(pkg)) { > // > // New package - add new > pkg=prefix mapping > // assignment > // > String prefix = > XmlSchemaHelpers.generateXmlPrefix( > pkg, this.map); > this.map.put(pkg, prefix); > } > } else if > (XmlSchemaHelpers.isUnbounded(argType)) { > String pkg = PluginConstants > .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); > if (!this.map.containsKey(pkg)) { > // > // New package - add new > pkg=prefix mapping > // assignment > // > String prefix = > XmlSchemaHelpers.generateXmlPrefix( > pkg, this.map); > this.map.put(pkg, prefix); > } > } else { > // XSD default namespace is enough > } > > and in the build of the closure we have got (this > fails as reported Craig): > > if ("objectName".equalsIgnoreCase(type.getName())){ > PluginLog.logDebug("type \'" + type > + "\' is an array of primitive."); > addReferencedPackage(PluginConstants > .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); > }else if (XmlSchemaHelpers.isUnbounded(type)){ > //will map to array of primitive > addReferencedPackage(PluginConstants > .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); > } else { > //normal primtive like xsd:int > } > > so the filtering never is considered. > > I will perform clean tests because was very difficult > to find the real cause of the problem, the log file is > not very clear in debug scenarios ( a lot of similar > log text, no log from the templates and also cannot > put the line number in the log file (tigerstripe > issue)) and these problems have delayed my response. > If the test go ok I will check out the changes to the > trunk > > https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator > > Best regards > > > El 01/06/2012 16:58, Craig Gallen escribió: > > Hi, > > > > I agree it is defined in internal_filter.xsd but it doesn't seem to be > > referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java > > throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also > > shows an error. > > > > I think Xose is looking into it > > > > Craig > > > > -----Original Message----- > > From: Flauw, Marc [mailto:Mar...@hp...] > > Sent: 01 June 2012 10:25 > > To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre > > gauthier > > Subject: RE: Problems with PM XSD generation > > > > Craig, > > > > There is one same filter in the getReosurceAlarms operation, filter > > argument. > > The XPathFilter is defined in the internal_filter.xsd > > > > Best regards > > > > Marc > > > > -----Original Message----- > > From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig > > Gallen (opennms) > > Sent: Thursday, May 31, 2012 11:58 PM > > To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier > > Subject: Problems with PM XSD generation > > > > Hi, > > > > I have been testing the TIP_PM_Col project model and have found that the > > dep_cbe_perf_spec.xsd (attached) file is generated with errors > > > > in line 62 we have > > <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" > > minOccurs="0" maxOccurs="1"> > > > > filter:XPathQueryFilter is not defined and if you open the file in eclipse > > it reports this error as: > > > > 's4s-att-invalid-value: Invalid attribute value for 'type' in element > > 'element'. Recorded reason: > > UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: > > the prefix 'filter' is not > > declared'. > > > > Is this a known problem or a new bug? > > > > Craig > > > > -- > > *Xose Ramon Sousa Vazquez*| Director OSS Technologies, > Director I+D > T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 > www.optaresolutions.com > <http://www.optaresolutions.com> > Optare Solutions <http://optarecoolvendor.com> > > -- > > *Xose Ramon Sousa Vazquez*| Director OSS Technologies, > Director I+D > T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 > www.optaresolutions.com > <http://www.optaresolutions.com> > Optare Solutions <http://optarecoolvendor.com> > > -- > > *Xose Ramon Sousa Vazquez*| Director OSS Technologies, > Director I+D > T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 > www.optaresolutions.com > <http://www.optaresolutions.com> > Optare Solutions <http://optarecoolvendor.com> > > -- > > *Xose Ramon Sousa Vazquez*| Director OSS Technologies, > Director I+D > T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 > www.optaresolutions.com > <http://www.optaresolutions.com> > Optare Solutions <http://optarecoolvendor.com> > > -- > > *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D > T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 > www.optaresolutions.com > <http://www.optaresolutions.com> > Optare Solutions <http://optarecoolvendor.com> > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Craig G. (opennms) <cg...@op...> - 2012-07-02 13:40:39
|
Hi Xose, Duncan from Tigerstripe has replied on bugzilla that we need to uncheck the "Run All Rules as Local" https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728 . I have run the MPAC model with "Run All Rules as Local" checked and then as unchecked to ensure that the property is correctly set in tigerstripe.xml. However this does not appear to fix the problem. Dependencies are not being generated by the soap plugin. Could you run the test in your model and get back to Duncan if it is still the issue. Thanks Craig On 28/06/2012 08:22, Xose Ramon Sousa Vazquez wrote: > I have created the bug > Bug 383728 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>has > been added to the database > > Email sent to: > |dke...@ci...|,|erd...@ci...|,|tig...@ec...|,|jis...@ci...|,|rcr...@ci...| > Excluding: > |xr...@op...| > > > > Regards > El 28/06/2012 9:18, Flauw, Marc escribió: >> >> Xose, >> >> Send us the bug pointer and I will escalate it . >> >> Best regards >> >> Marc >> >> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >> *Sent:* Thursday, June 28, 2012 9:17 AM >> *To:* Craig Gallen (opennms) >> *Cc:* 'openoss-devel'; Craig Gallen (entimoss); 'pierre gauthier' >> *Subject:* Re: [Openoss-devel] Problems with PM XSD generation >> >> Hi all. >> I have post the problem in the user list as the bug creation >> recommends. Nobody answer that so I am going to create the bug. I >> have a first version of the workaround but aome problems are derived >> in the cast operations in the src_shared classes, so I must >> investigate deeper. If this issue is solved I can send you Craig a >> preeliminary patch and then check the behaivour of the other $allxxxx >> context elements. >> >> >> Regards >> El 28/06/2012 6:32, Craig Gallen (opennms) escribió: >> >> Xose & Marc, >> >> Is there a plan to complete primitive.url / primitive.uri in the >> soap generator. I have support for it in the Java generators but >> need the Soap generator working with this stereotype to test this >> code. >> >> Also has a bug been raised against Tigerstripe for the >> $allPackage issue ? I'd prefer to fix the problem in tigerstripe >> rather than have Xose get a work around because if this isnt >> working, its possible other 'get all collections' of artificates >> are not working. So this could be a general problem for the other >> generators including Cisco's own. >> >> Xose, have you raised a bug report and if so what is the bug >> number? >> >> Marc, when we have a bug report, can we escalate this directly to >> the tigerstripe team because it is a show stopper for us. >> >> I'm afraid I cannot do any more development until this is fixed. >> >> Thanks for your help >> >> Craig >> >> >> >> >> >> >> On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: >> >> I am going to test a workaround to see if this could be >> supported without change the tigerstripe core. >> >> Regards >> El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: >> >> Hi, >> >> So is there a work around or do we have to wait for >> Tigerstripe to sort this out. >> The old version of tigerstripe (6.9.xxx) is no longer >> available to download. >> >> Craig >> >> On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >> >> Thanks Craig. >> I have performed some test and I can see an error in >> the Default Velocity context contents. When the >> $allPackage variable is used in the >> dependencyAnalyzer.vm template, it is expected that >> all artifacts, including the dependences, are >> included in that collection. In my tests I've got >> this behaivour: >> >> Old version of tigerstripe( Tigerstripe Core >> (Incubation) 0.6.935.201102010903 >> org.eclipse.tigerstripe.base.feature.group) >> %%%Calculate the dependencies/closure with >> [org.tmforum.tip.resource.trouble.alarm(370509597), >> org.tmforum.tip.resource.trouble(428889018), >> org.tmforum.tip.resource(240211633), >> org.tmforum.tip.cbe.perf(1039318676), >> org.tmforum.tip.common.notifications(23492680), >> org.tmforum.tip.resource.res(1133197283), >> org.tmforum.tip.cbe.root(1039387789), >> org.tmforum.tip(-660924437), >> org.tmforum.tip.cbe.root._char(-1449023596), >> org.tmforum(1644248382), org(110308), >> org.tmforum.tip.common(442435918), >> org.tmforum.tip.cbe.party(-2140978021), >> org.tmforum.tip.cbe.problem(292836116), >> org.tmforum.tip.cbe.root.tip.fmk(693071952), >> org.tmforum.tip.internal.filter(-1708340282), >> org.tmforum.tip.internal.extensibility(-1665414181), >> org.tmforum.tip.internal(1151687008), >> org.tmforum.tip.cbe.root.tip(1325885370), >> org.tmforum.tip.internal.notifications(-1680981798), >> org.tmforum.tip.common.exceptions(234099364), >> org.tmforum.tip.cbe.party.role(1514413545), >> org.tmforum.tip.internal.entity(-1732123599), >> org.tmforum.tip.resource.res.tip(-1716701168), >> org.tmforum.tip.internal.exceptions(-367434926), >> org.tmforum.tip.cbe(1681757027), >> org.tmforum.tip.internal.iterator(866200892), >> org.tmforum.tip.resource.res.tip.nrb(290014272)] >> [2012-06-26 10:21:29.996+0200] >> >> New version og tigerstripe( Tigerstripe Core >> (Incubation) 0.7.0.201206181258 >> org.eclipse.tigerstripe.base.feature.group): >> %%%Calculate the dependencies/closure with >> [org.tmforum.tip.resource.trouble.alarm(370509597), >> org.tmforum.tip.resource.trouble(428889018), >> org.tmforum.tip.resource(240211633)] [2012-06-26 >> 10:28:54.989+0200] >> >> So it seems that this is root cause for the missed files. >> I will create a bug in Tigerstripe. >> >> Regards >> >> El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: >> >> Hi >> From eclipse, Soap generator subversion; >> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >> Revision 3453 >> (last change revision 3444 last commit author xrsousa) >> >> Craig >> >> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >> >> Hi Craig, when you talk about the updated Soap >> Plugin, which version (in svn url) are using?, >> because the two first issues seems to be solved in >> the trunk with the other Tigerstripe version. >> >> >> >> >> Regards >> El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: >> >> Hi Xose, >> >> I just updated my tigerstripe to the latest release >> 0.7.0.20120618258 but Ialso updated the Soap plug-in >> and have found multiple problems but I am not sure if >> they are all related to the tigerstripe upgrade or to >> the current state of the soap plugin. Could you build >> the RAM project and check the generated XSD's to see >> the problem. >> >> 1. when you build the RAM project there is a problem >> with model closure. None of the Dependency XSD's get >> generated in the RAM_Model project >> >> 2. TrackingRecordResultWithIterator referenced as >> 'problem:TrackingRecordResultWithIterator' in >> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd >> is never generated. >> >> 3. Tigerstripe 0.7.0.20120618258. handles >> primitive.string differently and generates type >> 'String' instead of 'java.lang.String' this results >> in type :String instead of xsd:string. I did a quick >> fix given in the following patch adding >> || >> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >> >> to >> || >> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >> this means that old and new versions of tigerstipe >> will work >> >> There is a patch below but havent checked this in >> because I was not sure that else you were doing to >> the Soap plugin >> >> Craig >> >> >> >> ### Eclipse Workspace Patch 1.0 >> #P TIP_Soap_Generator >> Index: >> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >> =================================================================== >> --- >> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >> (revision 3453) >> +++ >> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >> (working copy) >> @@ -510,8 +510,8 @@ >> */ >> if (refType.isPrimitive() >> || >> refType.getPackage().equalsIgnoreCase("primitive") >> - || >> "java.lang.String".equalsIgnoreCase(refType >> - .getFullyQualifiedName())) { >> + || >> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >> + || >> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >> { // tigerstripe 1.7.0 now generates String and not >> java.lang.String >> PluginLog.logDebug("\'" + refTypeFullName >> + "\' is a primitive type in >> current TIP profile."); >> type = >> mapPrimitivesToXsdType(refType.getName(), >> isArray(refType), >> @@ -519,7 +519,7 @@ >> } >> >> /** >> - * Map datatyeps and enumerations >> + * Map datatypes and enumerations >> */ >> // if (refType.isDatatype() || refType.isEnum() >> else if (isDatatype(refType) || >> isEnumeration(refType)) { >> Index: >> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >> =================================================================== >> --- >> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >> (revision 3453) >> +++ >> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >> (working copy) >> @@ -170,8 +170,9 @@ >> private void addReferencedPackage(IType type) { >> >> if (type.isPrimitive() >> - || >> "primitive".equalsIgnoreCase(type.getPackage()) || >> - >> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) >> { >> + || >> "primitive".equalsIgnoreCase(type.getPackage()) >> + || >> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >> + || >> "String".equalsIgnoreCase(type.getFullyQualifiedName())) >> { // tigerstripe 1.7.0 now generates String and not >> java.lang.String >> //will map objectName to >> EntityIdentifier or ArrayOfEntityIdentifier >> if >> ("objectName".equalsIgnoreCase(type.getName())){ >> PluginLog.logDebug("type \'" + type >> @@ -378,8 +379,8 @@ >> */ >> if (refType.isPrimitive() >> || >> refType.getPackage().equalsIgnoreCase("primitive") >> - || >> "java.lang.String".equalsIgnoreCase(refType >> - .getFullyQualifiedName())) { >> + || >> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >> + || >> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >> { // tigerstripe 1.7.0 now generates String and not >> java.lang.String >> PluginLog.logDebug("\'" + typeName >> + "\' is a primitive type in >> current TIP profile."); >> >> >> >> >> >> >> >> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >> >> Hi all. I think that I have found the error and I >> will try to fix it as soon as possible. There are >> some related issues, one error in the codification of >> a method and a forgetted evaluation of filtering in >> the velocity template and also a case related with >> primitive type filter not supported in the build of >> the closure outside the interfaces. >> >> In the interfaces build the search is performed as >> follows(this works fine as reported Marc): >> >> if >> ("objectName".equalsIgnoreCase(argType.getName())) { >> /* >> * This data type >> 'objectName' defines the protocol >> * neutral unique name of an >> object. This data type will >> * be replaced by the >> generators by an EntityIdentifier >> */ >> String pkg = PluginConstants >> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >> if (!this.map.containsKey(pkg)) { >> // >> // New package - add new >> pkg=prefix mapping >> // assignment >> // >> String prefix = >> XmlSchemaHelpers.generateXmlPrefix( >> pkg, this.map); >> this.map.put(pkg, prefix); >> } >> } else if >> ("filter".equalsIgnoreCase(argType.getName())) { >> /* >> * This data type 'filter'. >> This data type will >> * be replaced by the >> generator to >> */ >> String pkg = PluginConstants >> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >> if (!this.map.containsKey(pkg)) { >> // >> // New package - add new >> pkg=prefix mapping >> // assignment >> // >> String prefix = >> XmlSchemaHelpers.generateXmlPrefix( >> pkg, this.map); >> this.map.put(pkg, prefix); >> } >> } else if >> (XmlSchemaHelpers.isUnbounded(argType)) { >> String pkg = PluginConstants >> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >> if (!this.map.containsKey(pkg)) { >> // >> // New package - add new >> pkg=prefix mapping >> // assignment >> // >> String prefix = >> XmlSchemaHelpers.generateXmlPrefix( >> pkg, this.map); >> this.map.put(pkg, prefix); >> } >> } else { >> // XSD default namespace is >> enough >> } >> >> and in the build of the closure we have got (this >> fails as reported Craig): >> >> if ("objectName".equalsIgnoreCase(type.getName())){ >> PluginLog.logDebug("type \'" + type >> + "\' is an array of primitive."); >> addReferencedPackage(PluginConstants >> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >> }else if >> (XmlSchemaHelpers.isUnbounded(type)){ >> //will map to array of primitive >> addReferencedPackage(PluginConstants >> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >> } else { >> //normal primtive like xsd:int >> } >> >> so the filtering never is considered. >> >> I will perform clean tests because was very difficult >> to find the real cause of the problem, the log file >> is not very clear in debug scenarios ( a lot of >> similar log text, no log from the templates and also >> cannot put the line number in the log file >> (tigerstripe issue)) and these problems have delayed >> my response. >> If the test go ok I will check out the changes to the >> trunk >> >> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >> >> Best regards >> >> >> El 01/06/2012 16:58, Craig Gallen escribió: >> >> Hi, >> >> >> >> I agree it is defined in internal_filter.xsd but it doesn't seem to be >> >> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >> >> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >> >> shows an error. >> >> >> >> I think Xose is looking into it >> >> >> >> Craig >> >> >> >> -----Original Message----- >> >> From: Flauw, Marc [mailto:Mar...@hp...] >> >> Sent: 01 June 2012 10:25 >> >> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >> >> gauthier >> >> Subject: RE: Problems with PM XSD generation >> >> >> >> Craig, >> >> >> >> There is one same filter in the getReosurceAlarms operation, filter >> >> argument. >> >> The XPathFilter is defined in the internal_filter.xsd >> >> >> >> Best regards >> >> >> >> Marc >> >> >> >> -----Original Message----- >> >> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >> >> Gallen (opennms) >> >> Sent: Thursday, May 31, 2012 11:58 PM >> >> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >> >> Subject: Problems with PM XSD generation >> >> >> >> Hi, >> >> >> >> I have been testing the TIP_PM_Col project model and have found that the >> >> dep_cbe_perf_spec.xsd (attached) file is generated with errors >> >> >> >> in line 62 we have >> >> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >> >> minOccurs="0" maxOccurs="1"> >> >> >> >> filter:XPathQueryFilter is not defined and if you open the file in eclipse >> >> it reports this error as: >> >> >> >> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >> >> 'element'. Recorded reason: >> >> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >> >> the prefix 'filter' is not >> >> declared'. >> >> >> >> Is this a known problem or a new bug? >> >> >> >> Craig >> >> >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS >> Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions <http://optarecoolvendor.com> >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS >> Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions <http://optarecoolvendor.com> >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS >> Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions <http://optarecoolvendor.com> >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >> Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions <http://optarecoolvendor.com> >> >> -- >> >> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions <http://optarecoolvendor.com> >> > > > -- > > *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D > T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 > www.optaresolutions.com > <http://www.optaresolutions.com> > Optare Solutions > <http://optarecoolvendor.com><http://optarecoolvendor.com> > |
|
From: Xose R. S. V. <xr...@op...> - 2012-07-02 14:34:22
|
I have responsed that to Duncan on Friday. I am going to send again. In the workaround I am dealing with a Proxy implementation of hte artifacts in these new version that give some problems in filter the packages among allArtifacts. I am going to resend the response to Duncan. Regards El 02/07/2012 15:40, Craig Gallen (opennms) escribió: > Hi Xose, > > Duncan from Tigerstripe has replied on bugzilla that we need to > uncheck the "Run All Rules as Local" > https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728 . I have run the > MPAC model with "Run All Rules as Local" checked and then as unchecked > to ensure that the property is correctly set in tigerstripe.xml. > However this does not appear to fix the problem. Dependencies are not > being generated by the soap plugin. Could you run the test in your > model and get back to Duncan if it is still the issue. > > Thanks > > Craig > > > > > > On 28/06/2012 08:22, Xose Ramon Sousa Vazquez wrote: >> I have created the bug >> Bug 383728 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>has >> been added to the database >> >> Email sent to: >> |dke...@ci...|,|erd...@ci...|,|tig...@ec...|,|jis...@ci...|,|rcr...@ci...| >> Excluding: >> |xr...@op...| >> >> >> >> Regards >> El 28/06/2012 9:18, Flauw, Marc escribió: >>> >>> Xose, >>> >>> Send us the bug pointer and I will escalate it . >>> >>> Best regards >>> >>> Marc >>> >>> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >>> *Sent:* Thursday, June 28, 2012 9:17 AM >>> *To:* Craig Gallen (opennms) >>> *Cc:* 'openoss-devel'; Craig Gallen (entimoss); 'pierre gauthier' >>> *Subject:* Re: [Openoss-devel] Problems with PM XSD generation >>> >>> Hi all. >>> I have post the problem in the user list as the bug creation >>> recommends. Nobody answer that so I am going to create the bug. I >>> have a first version of the workaround but aome problems are derived >>> in the cast operations in the src_shared classes, so I must >>> investigate deeper. If this issue is solved I can send you Craig a >>> preeliminary patch and then check the behaivour of the other >>> $allxxxx context elements. >>> >>> >>> Regards >>> El 28/06/2012 6:32, Craig Gallen (opennms) escribió: >>> >>> Xose & Marc, >>> >>> Is there a plan to complete primitive.url / primitive.uri in the >>> soap generator. I have support for it in the Java generators but >>> need the Soap generator working with this stereotype to test >>> this code. >>> >>> Also has a bug been raised against Tigerstripe for the >>> $allPackage issue ? I'd prefer to fix the problem in tigerstripe >>> rather than have Xose get a work around because if this isnt >>> working, its possible other 'get all collections' of artificates >>> are not working. So this could be a general problem for the >>> other generators including Cisco's own. >>> >>> Xose, have you raised a bug report and if so what is the bug >>> number? >>> >>> Marc, when we have a bug report, can we escalate this directly >>> to the tigerstripe team because it is a show stopper for us. >>> >>> I'm afraid I cannot do any more development until this is fixed. >>> >>> Thanks for your help >>> >>> Craig >>> >>> >>> >>> >>> >>> >>> On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: >>> >>> I am going to test a workaround to see if this could be >>> supported without change the tigerstripe core. >>> >>> Regards >>> El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: >>> >>> Hi, >>> >>> So is there a work around or do we have to wait for >>> Tigerstripe to sort this out. >>> The old version of tigerstripe (6.9.xxx) is no longer >>> available to download. >>> >>> Craig >>> >>> On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >>> >>> Thanks Craig. >>> I have performed some test and I can see an error in >>> the Default Velocity context contents. When the >>> $allPackage variable is used in the >>> dependencyAnalyzer.vm template, it is expected that >>> all artifacts, including the dependences, are >>> included in that collection. In my tests I've got >>> this behaivour: >>> >>> Old version of tigerstripe( Tigerstripe Core >>> (Incubation) 0.6.935.201102010903 >>> org.eclipse.tigerstripe.base.feature.group) >>> %%%Calculate the dependencies/closure with >>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>> org.tmforum.tip.resource.trouble(428889018), >>> org.tmforum.tip.resource(240211633), >>> org.tmforum.tip.cbe.perf(1039318676), >>> org.tmforum.tip.common.notifications(23492680), >>> org.tmforum.tip.resource.res(1133197283), >>> org.tmforum.tip.cbe.root(1039387789), >>> org.tmforum.tip(-660924437), >>> org.tmforum.tip.cbe.root._char(-1449023596), >>> org.tmforum(1644248382), org(110308), >>> org.tmforum.tip.common(442435918), >>> org.tmforum.tip.cbe.party(-2140978021), >>> org.tmforum.tip.cbe.problem(292836116), >>> org.tmforum.tip.cbe.root.tip.fmk(693071952), >>> org.tmforum.tip.internal.filter(-1708340282), >>> org.tmforum.tip.internal.extensibility(-1665414181), >>> org.tmforum.tip.internal(1151687008), >>> org.tmforum.tip.cbe.root.tip(1325885370), >>> org.tmforum.tip.internal.notifications(-1680981798), >>> org.tmforum.tip.common.exceptions(234099364), >>> org.tmforum.tip.cbe.party.role(1514413545), >>> org.tmforum.tip.internal.entity(-1732123599), >>> org.tmforum.tip.resource.res.tip(-1716701168), >>> org.tmforum.tip.internal.exceptions(-367434926), >>> org.tmforum.tip.cbe(1681757027), >>> org.tmforum.tip.internal.iterator(866200892), >>> org.tmforum.tip.resource.res.tip.nrb(290014272)] >>> [2012-06-26 10:21:29.996+0200] >>> >>> New version og tigerstripe( Tigerstripe Core >>> (Incubation) 0.7.0.201206181258 >>> org.eclipse.tigerstripe.base.feature.group): >>> %%%Calculate the dependencies/closure with >>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>> org.tmforum.tip.resource.trouble(428889018), >>> org.tmforum.tip.resource(240211633)] [2012-06-26 >>> 10:28:54.989+0200] >>> >>> So it seems that this is root cause for the missed >>> files. >>> I will create a bug in Tigerstripe. >>> >>> Regards >>> >>> El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: >>> >>> Hi >>> From eclipse, Soap generator subversion; >>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>> Revision 3453 >>> (last change revision 3444 last commit author xrsousa) >>> >>> Craig >>> >>> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >>> >>> Hi Craig, when you talk about the updated Soap >>> Plugin, which version (in svn url) are using?, >>> because the two first issues seems to be solved in >>> the trunk with the other Tigerstripe version. >>> >>> >>> >>> >>> Regards >>> El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: >>> >>> Hi Xose, >>> >>> I just updated my tigerstripe to the latest release >>> 0.7.0.20120618258 but Ialso updated the Soap plug-in >>> and have found multiple problems but I am not sure >>> if they are all related to the tigerstripe upgrade >>> or to the current state of the soap plugin. Could >>> you build the RAM project and check the generated >>> XSD's to see the problem. >>> >>> 1. when you build the RAM project there is a problem >>> with model closure. None of the Dependency XSD's >>> get generated in the RAM_Model project >>> >>> 2. TrackingRecordResultWithIterator referenced as >>> 'problem:TrackingRecordResultWithIterator' in >>> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd >>> is never generated. >>> >>> 3. Tigerstripe 0.7.0.20120618258. handles >>> primitive.string differently and generates type >>> 'String' instead of 'java.lang.String' this results >>> in type :String instead of xsd:string. I did a >>> quick fix given in the following patch adding >>> || >>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>> >>> to >>> || >>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>> this means that old and new versions of tigerstipe >>> will work >>> >>> There is a patch below but havent checked this in >>> because I was not sure that else you were doing to >>> the Soap plugin >>> >>> Craig >>> >>> >>> >>> ### Eclipse Workspace Patch 1.0 >>> #P TIP_Soap_Generator >>> Index: >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>> =================================================================== >>> --- >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>> (revision 3453) >>> +++ >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>> (working copy) >>> @@ -510,8 +510,8 @@ >>> */ >>> if (refType.isPrimitive() >>> || >>> refType.getPackage().equalsIgnoreCase("primitive") >>> - || >>> "java.lang.String".equalsIgnoreCase(refType >>> - .getFullyQualifiedName())) { >>> + || >>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>> + || >>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>> { // tigerstripe 1.7.0 now generates String and not >>> java.lang.String >>> PluginLog.logDebug("\'" + refTypeFullName >>> + "\' is a primitive type in >>> current TIP profile."); >>> type = >>> mapPrimitivesToXsdType(refType.getName(), >>> isArray(refType), >>> @@ -519,7 +519,7 @@ >>> } >>> >>> /** >>> - * Map datatyeps and enumerations >>> + * Map datatypes and enumerations >>> */ >>> // if (refType.isDatatype() || refType.isEnum() >>> else if (isDatatype(refType) || >>> isEnumeration(refType)) { >>> Index: >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>> =================================================================== >>> --- >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>> (revision 3453) >>> +++ >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>> (working copy) >>> @@ -170,8 +170,9 @@ >>> private void addReferencedPackage(IType type) { >>> >>> if (type.isPrimitive() >>> - || >>> "primitive".equalsIgnoreCase(type.getPackage()) || >>> - >>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) >>> { >>> + || >>> "primitive".equalsIgnoreCase(type.getPackage()) >>> + || >>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>> + || >>> "String".equalsIgnoreCase(type.getFullyQualifiedName())) >>> { // tigerstripe 1.7.0 now generates String and not >>> java.lang.String >>> //will map objectName to >>> EntityIdentifier or ArrayOfEntityIdentifier >>> if >>> ("objectName".equalsIgnoreCase(type.getName())){ >>> PluginLog.logDebug("type \'" + type >>> @@ -378,8 +379,8 @@ >>> */ >>> if (refType.isPrimitive() >>> || >>> refType.getPackage().equalsIgnoreCase("primitive") >>> - || >>> "java.lang.String".equalsIgnoreCase(refType >>> - .getFullyQualifiedName())) { >>> + || >>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>> + || >>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>> { // tigerstripe 1.7.0 now generates String and not >>> java.lang.String >>> PluginLog.logDebug("\'" + typeName >>> + "\' is a primitive type in >>> current TIP profile."); >>> >>> >>> >>> >>> >>> >>> >>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>> >>> Hi all. I think that I have found the error and I >>> will try to fix it as soon as possible. There are >>> some related issues, one error in the codification >>> of a method and a forgetted evaluation of filtering >>> in the velocity template and also a case related >>> with primitive type filter not supported in the >>> build of the closure outside the interfaces. >>> >>> In the interfaces build the search is performed as >>> follows(this works fine as reported Marc): >>> >>> if >>> ("objectName".equalsIgnoreCase(argType.getName())) { >>> /* >>> * This data type >>> 'objectName' defines the protocol >>> * neutral unique name of an >>> object. This data type will >>> * be replaced by the >>> generators by an EntityIdentifier >>> */ >>> String pkg = PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>> if >>> (!this.map.containsKey(pkg)) { >>> // >>> // New package - add new >>> pkg=prefix mapping >>> // assignment >>> // >>> String prefix = >>> XmlSchemaHelpers.generateXmlPrefix( >>> pkg, this.map); >>> this.map.put(pkg, prefix); >>> } >>> } else if >>> ("filter".equalsIgnoreCase(argType.getName())) { >>> /* >>> * This data type 'filter'. >>> This data type will >>> * be replaced by the >>> generator to >>> */ >>> String pkg = PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >>> if >>> (!this.map.containsKey(pkg)) { >>> // >>> // New package - add new >>> pkg=prefix mapping >>> // assignment >>> // >>> String prefix = >>> XmlSchemaHelpers.generateXmlPrefix( >>> pkg, this.map); >>> this.map.put(pkg, prefix); >>> } >>> } else if >>> (XmlSchemaHelpers.isUnbounded(argType)) { >>> String pkg = PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >>> if >>> (!this.map.containsKey(pkg)) { >>> // >>> // New package - add new >>> pkg=prefix mapping >>> // assignment >>> // >>> String prefix = >>> XmlSchemaHelpers.generateXmlPrefix( >>> pkg, this.map); >>> this.map.put(pkg, prefix); >>> } >>> } else { >>> // XSD default namespace is >>> enough >>> } >>> >>> and in the build of the closure we have got (this >>> fails as reported Craig): >>> >>> if ("objectName".equalsIgnoreCase(type.getName())){ >>> PluginLog.logDebug("type \'" + type >>> + "\' is an array of primitive."); >>> addReferencedPackage(PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >>> }else if >>> (XmlSchemaHelpers.isUnbounded(type)){ >>> //will map to array of primitive >>> addReferencedPackage(PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >>> } else { >>> //normal primtive like xsd:int >>> } >>> >>> so the filtering never is considered. >>> >>> I will perform clean tests because was very >>> difficult to find the real cause of the problem, the >>> log file is not very clear in debug scenarios ( a >>> lot of similar log text, no log from the templates >>> and also cannot put the line number in the log file >>> (tigerstripe issue)) and these problems have delayed >>> my response. >>> If the test go ok I will check out the changes to >>> the trunk >>> >>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>> >>> Best regards >>> >>> >>> El 01/06/2012 16:58, Craig Gallen escribió: >>> >>> Hi, >>> >>> >>> >>> I agree it is defined in internal_filter.xsd but it doesn't seem to be >>> >>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >>> >>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >>> >>> shows an error. >>> >>> >>> >>> I think Xose is looking into it >>> >>> >>> >>> Craig >>> >>> >>> >>> -----Original Message----- >>> >>> From: Flauw, Marc [mailto:Mar...@hp...] >>> >>> Sent: 01 June 2012 10:25 >>> >>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >>> >>> gauthier >>> >>> Subject: RE: Problems with PM XSD generation >>> >>> >>> >>> Craig, >>> >>> >>> >>> There is one same filter in the getReosurceAlarms operation, filter >>> >>> argument. >>> >>> The XPathFilter is defined in the internal_filter.xsd >>> >>> >>> >>> Best regards >>> >>> >>> >>> Marc >>> >>> >>> >>> -----Original Message----- >>> >>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >>> >>> Gallen (opennms) >>> >>> Sent: Thursday, May 31, 2012 11:58 PM >>> >>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >>> >>> Subject: Problems with PM XSD generation >>> >>> >>> >>> Hi, >>> >>> >>> >>> I have been testing the TIP_PM_Col project model and have found that the >>> >>> dep_cbe_perf_spec.xsd (attached) file is generated with errors >>> >>> >>> >>> in line 62 we have >>> >>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >>> >>> minOccurs="0" maxOccurs="1"> >>> >>> >>> >>> filter:XPathQueryFilter is not defined and if you open the file in eclipse >>> >>> it reports this error as: >>> >>> >>> >>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >>> >>> 'element'. Recorded reason: >>> >>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >>> >>> the prefix 'filter' is not >>> >>> declared'. >>> >>> >>> >>> Is this a known problem or a new bug? >>> >>> >>> >>> Craig >>> >>> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS >>> Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS >>> Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS >>> Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >>> Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >> >> >> -- >> >> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions >> <http://optarecoolvendor.com><http://optarecoolvendor.com> >> > > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Xose R. S. V. <xr...@op...> - 2012-07-03 10:41:30
|
Hi all. I am developing a module that get the packages to perform the funcionallity desired, but in the models there are changes in the way they are instantied so a deeper revision is needed. I have got the code to obtain the packages and now we are changing the models, but has a lot of dependences in building the closure. I am trying to finish it and the publish on the sandbox area better to perform tests and avoid regression problems. Regards El 02/07/2012 15:40, Craig Gallen (opennms) escribió: > Hi Xose, > > Duncan from Tigerstripe has replied on bugzilla that we need to > uncheck the "Run All Rules as Local" > https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728 . I have run the > MPAC model with "Run All Rules as Local" checked and then as unchecked > to ensure that the property is correctly set in tigerstripe.xml. > However this does not appear to fix the problem. Dependencies are not > being generated by the soap plugin. Could you run the test in your > model and get back to Duncan if it is still the issue. > > Thanks > > Craig > > > > > > On 28/06/2012 08:22, Xose Ramon Sousa Vazquez wrote: >> I have created the bug >> Bug 383728 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>has >> been added to the database >> >> Email sent to: >> |dke...@ci...|,|erd...@ci...|,|tig...@ec...|,|jis...@ci...|,|rcr...@ci...| >> Excluding: >> |xr...@op...| >> >> >> >> Regards >> El 28/06/2012 9:18, Flauw, Marc escribió: >>> >>> Xose, >>> >>> Send us the bug pointer and I will escalate it . >>> >>> Best regards >>> >>> Marc >>> >>> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >>> *Sent:* Thursday, June 28, 2012 9:17 AM >>> *To:* Craig Gallen (opennms) >>> *Cc:* 'openoss-devel'; Craig Gallen (entimoss); 'pierre gauthier' >>> *Subject:* Re: [Openoss-devel] Problems with PM XSD generation >>> >>> Hi all. >>> I have post the problem in the user list as the bug creation >>> recommends. Nobody answer that so I am going to create the bug. I >>> have a first version of the workaround but aome problems are derived >>> in the cast operations in the src_shared classes, so I must >>> investigate deeper. If this issue is solved I can send you Craig a >>> preeliminary patch and then check the behaivour of the other >>> $allxxxx context elements. >>> >>> >>> Regards >>> El 28/06/2012 6:32, Craig Gallen (opennms) escribió: >>> >>> Xose & Marc, >>> >>> Is there a plan to complete primitive.url / primitive.uri in the >>> soap generator. I have support for it in the Java generators but >>> need the Soap generator working with this stereotype to test >>> this code. >>> >>> Also has a bug been raised against Tigerstripe for the >>> $allPackage issue ? I'd prefer to fix the problem in tigerstripe >>> rather than have Xose get a work around because if this isnt >>> working, its possible other 'get all collections' of artificates >>> are not working. So this could be a general problem for the >>> other generators including Cisco's own. >>> >>> Xose, have you raised a bug report and if so what is the bug >>> number? >>> >>> Marc, when we have a bug report, can we escalate this directly >>> to the tigerstripe team because it is a show stopper for us. >>> >>> I'm afraid I cannot do any more development until this is fixed. >>> >>> Thanks for your help >>> >>> Craig >>> >>> >>> >>> >>> >>> >>> On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: >>> >>> I am going to test a workaround to see if this could be >>> supported without change the tigerstripe core. >>> >>> Regards >>> El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: >>> >>> Hi, >>> >>> So is there a work around or do we have to wait for >>> Tigerstripe to sort this out. >>> The old version of tigerstripe (6.9.xxx) is no longer >>> available to download. >>> >>> Craig >>> >>> On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >>> >>> Thanks Craig. >>> I have performed some test and I can see an error in >>> the Default Velocity context contents. When the >>> $allPackage variable is used in the >>> dependencyAnalyzer.vm template, it is expected that >>> all artifacts, including the dependences, are >>> included in that collection. In my tests I've got >>> this behaivour: >>> >>> Old version of tigerstripe( Tigerstripe Core >>> (Incubation) 0.6.935.201102010903 >>> org.eclipse.tigerstripe.base.feature.group) >>> %%%Calculate the dependencies/closure with >>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>> org.tmforum.tip.resource.trouble(428889018), >>> org.tmforum.tip.resource(240211633), >>> org.tmforum.tip.cbe.perf(1039318676), >>> org.tmforum.tip.common.notifications(23492680), >>> org.tmforum.tip.resource.res(1133197283), >>> org.tmforum.tip.cbe.root(1039387789), >>> org.tmforum.tip(-660924437), >>> org.tmforum.tip.cbe.root._char(-1449023596), >>> org.tmforum(1644248382), org(110308), >>> org.tmforum.tip.common(442435918), >>> org.tmforum.tip.cbe.party(-2140978021), >>> org.tmforum.tip.cbe.problem(292836116), >>> org.tmforum.tip.cbe.root.tip.fmk(693071952), >>> org.tmforum.tip.internal.filter(-1708340282), >>> org.tmforum.tip.internal.extensibility(-1665414181), >>> org.tmforum.tip.internal(1151687008), >>> org.tmforum.tip.cbe.root.tip(1325885370), >>> org.tmforum.tip.internal.notifications(-1680981798), >>> org.tmforum.tip.common.exceptions(234099364), >>> org.tmforum.tip.cbe.party.role(1514413545), >>> org.tmforum.tip.internal.entity(-1732123599), >>> org.tmforum.tip.resource.res.tip(-1716701168), >>> org.tmforum.tip.internal.exceptions(-367434926), >>> org.tmforum.tip.cbe(1681757027), >>> org.tmforum.tip.internal.iterator(866200892), >>> org.tmforum.tip.resource.res.tip.nrb(290014272)] >>> [2012-06-26 10:21:29.996+0200] >>> >>> New version og tigerstripe( Tigerstripe Core >>> (Incubation) 0.7.0.201206181258 >>> org.eclipse.tigerstripe.base.feature.group): >>> %%%Calculate the dependencies/closure with >>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>> org.tmforum.tip.resource.trouble(428889018), >>> org.tmforum.tip.resource(240211633)] [2012-06-26 >>> 10:28:54.989+0200] >>> >>> So it seems that this is root cause for the missed >>> files. >>> I will create a bug in Tigerstripe. >>> >>> Regards >>> >>> El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: >>> >>> Hi >>> From eclipse, Soap generator subversion; >>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>> Revision 3453 >>> (last change revision 3444 last commit author xrsousa) >>> >>> Craig >>> >>> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >>> >>> Hi Craig, when you talk about the updated Soap >>> Plugin, which version (in svn url) are using?, >>> because the two first issues seems to be solved in >>> the trunk with the other Tigerstripe version. >>> >>> >>> >>> >>> Regards >>> El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: >>> >>> Hi Xose, >>> >>> I just updated my tigerstripe to the latest release >>> 0.7.0.20120618258 but Ialso updated the Soap plug-in >>> and have found multiple problems but I am not sure >>> if they are all related to the tigerstripe upgrade >>> or to the current state of the soap plugin. Could >>> you build the RAM project and check the generated >>> XSD's to see the problem. >>> >>> 1. when you build the RAM project there is a problem >>> with model closure. None of the Dependency XSD's >>> get generated in the RAM_Model project >>> >>> 2. TrackingRecordResultWithIterator referenced as >>> 'problem:TrackingRecordResultWithIterator' in >>> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd >>> is never generated. >>> >>> 3. Tigerstripe 0.7.0.20120618258. handles >>> primitive.string differently and generates type >>> 'String' instead of 'java.lang.String' this results >>> in type :String instead of xsd:string. I did a >>> quick fix given in the following patch adding >>> || >>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>> >>> to >>> || >>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>> this means that old and new versions of tigerstipe >>> will work >>> >>> There is a patch below but havent checked this in >>> because I was not sure that else you were doing to >>> the Soap plugin >>> >>> Craig >>> >>> >>> >>> ### Eclipse Workspace Patch 1.0 >>> #P TIP_Soap_Generator >>> Index: >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>> =================================================================== >>> --- >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>> (revision 3453) >>> +++ >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>> (working copy) >>> @@ -510,8 +510,8 @@ >>> */ >>> if (refType.isPrimitive() >>> || >>> refType.getPackage().equalsIgnoreCase("primitive") >>> - || >>> "java.lang.String".equalsIgnoreCase(refType >>> - .getFullyQualifiedName())) { >>> + || >>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>> + || >>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>> { // tigerstripe 1.7.0 now generates String and not >>> java.lang.String >>> PluginLog.logDebug("\'" + refTypeFullName >>> + "\' is a primitive type in >>> current TIP profile."); >>> type = >>> mapPrimitivesToXsdType(refType.getName(), >>> isArray(refType), >>> @@ -519,7 +519,7 @@ >>> } >>> >>> /** >>> - * Map datatyeps and enumerations >>> + * Map datatypes and enumerations >>> */ >>> // if (refType.isDatatype() || refType.isEnum() >>> else if (isDatatype(refType) || >>> isEnumeration(refType)) { >>> Index: >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>> =================================================================== >>> --- >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>> (revision 3453) >>> +++ >>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>> (working copy) >>> @@ -170,8 +170,9 @@ >>> private void addReferencedPackage(IType type) { >>> >>> if (type.isPrimitive() >>> - || >>> "primitive".equalsIgnoreCase(type.getPackage()) || >>> - >>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) >>> { >>> + || >>> "primitive".equalsIgnoreCase(type.getPackage()) >>> + || >>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>> + || >>> "String".equalsIgnoreCase(type.getFullyQualifiedName())) >>> { // tigerstripe 1.7.0 now generates String and not >>> java.lang.String >>> //will map objectName to >>> EntityIdentifier or ArrayOfEntityIdentifier >>> if >>> ("objectName".equalsIgnoreCase(type.getName())){ >>> PluginLog.logDebug("type \'" + type >>> @@ -378,8 +379,8 @@ >>> */ >>> if (refType.isPrimitive() >>> || >>> refType.getPackage().equalsIgnoreCase("primitive") >>> - || >>> "java.lang.String".equalsIgnoreCase(refType >>> - .getFullyQualifiedName())) { >>> + || >>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>> + || >>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>> { // tigerstripe 1.7.0 now generates String and not >>> java.lang.String >>> PluginLog.logDebug("\'" + typeName >>> + "\' is a primitive type in >>> current TIP profile."); >>> >>> >>> >>> >>> >>> >>> >>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>> >>> Hi all. I think that I have found the error and I >>> will try to fix it as soon as possible. There are >>> some related issues, one error in the codification >>> of a method and a forgetted evaluation of filtering >>> in the velocity template and also a case related >>> with primitive type filter not supported in the >>> build of the closure outside the interfaces. >>> >>> In the interfaces build the search is performed as >>> follows(this works fine as reported Marc): >>> >>> if >>> ("objectName".equalsIgnoreCase(argType.getName())) { >>> /* >>> * This data type >>> 'objectName' defines the protocol >>> * neutral unique name of an >>> object. This data type will >>> * be replaced by the >>> generators by an EntityIdentifier >>> */ >>> String pkg = PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>> if >>> (!this.map.containsKey(pkg)) { >>> // >>> // New package - add new >>> pkg=prefix mapping >>> // assignment >>> // >>> String prefix = >>> XmlSchemaHelpers.generateXmlPrefix( >>> pkg, this.map); >>> this.map.put(pkg, prefix); >>> } >>> } else if >>> ("filter".equalsIgnoreCase(argType.getName())) { >>> /* >>> * This data type 'filter'. >>> This data type will >>> * be replaced by the >>> generator to >>> */ >>> String pkg = PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >>> if >>> (!this.map.containsKey(pkg)) { >>> // >>> // New package - add new >>> pkg=prefix mapping >>> // assignment >>> // >>> String prefix = >>> XmlSchemaHelpers.generateXmlPrefix( >>> pkg, this.map); >>> this.map.put(pkg, prefix); >>> } >>> } else if >>> (XmlSchemaHelpers.isUnbounded(argType)) { >>> String pkg = PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >>> if >>> (!this.map.containsKey(pkg)) { >>> // >>> // New package - add new >>> pkg=prefix mapping >>> // assignment >>> // >>> String prefix = >>> XmlSchemaHelpers.generateXmlPrefix( >>> pkg, this.map); >>> this.map.put(pkg, prefix); >>> } >>> } else { >>> // XSD default namespace is >>> enough >>> } >>> >>> and in the build of the closure we have got (this >>> fails as reported Craig): >>> >>> if ("objectName".equalsIgnoreCase(type.getName())){ >>> PluginLog.logDebug("type \'" + type >>> + "\' is an array of primitive."); >>> addReferencedPackage(PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >>> }else if >>> (XmlSchemaHelpers.isUnbounded(type)){ >>> //will map to array of primitive >>> addReferencedPackage(PluginConstants >>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >>> } else { >>> //normal primtive like xsd:int >>> } >>> >>> so the filtering never is considered. >>> >>> I will perform clean tests because was very >>> difficult to find the real cause of the problem, the >>> log file is not very clear in debug scenarios ( a >>> lot of similar log text, no log from the templates >>> and also cannot put the line number in the log file >>> (tigerstripe issue)) and these problems have delayed >>> my response. >>> If the test go ok I will check out the changes to >>> the trunk >>> >>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>> >>> Best regards >>> >>> >>> El 01/06/2012 16:58, Craig Gallen escribió: >>> >>> Hi, >>> >>> >>> >>> I agree it is defined in internal_filter.xsd but it doesn't seem to be >>> >>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >>> >>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >>> >>> shows an error. >>> >>> >>> >>> I think Xose is looking into it >>> >>> >>> >>> Craig >>> >>> >>> >>> -----Original Message----- >>> >>> From: Flauw, Marc [mailto:Mar...@hp...] >>> >>> Sent: 01 June 2012 10:25 >>> >>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >>> >>> gauthier >>> >>> Subject: RE: Problems with PM XSD generation >>> >>> >>> >>> Craig, >>> >>> >>> >>> There is one same filter in the getReosurceAlarms operation, filter >>> >>> argument. >>> >>> The XPathFilter is defined in the internal_filter.xsd >>> >>> >>> >>> Best regards >>> >>> >>> >>> Marc >>> >>> >>> >>> -----Original Message----- >>> >>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >>> >>> Gallen (opennms) >>> >>> Sent: Thursday, May 31, 2012 11:58 PM >>> >>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >>> >>> Subject: Problems with PM XSD generation >>> >>> >>> >>> Hi, >>> >>> >>> >>> I have been testing the TIP_PM_Col project model and have found that the >>> >>> dep_cbe_perf_spec.xsd (attached) file is generated with errors >>> >>> >>> >>> in line 62 we have >>> >>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >>> >>> minOccurs="0" maxOccurs="1"> >>> >>> >>> >>> filter:XPathQueryFilter is not defined and if you open the file in eclipse >>> >>> it reports this error as: >>> >>> >>> >>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >>> >>> 'element'. Recorded reason: >>> >>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >>> >>> the prefix 'filter' is not >>> >>> declared'. >>> >>> >>> >>> Is this a known problem or a new bug? >>> >>> >>> >>> Craig >>> >>> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS >>> Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS >>> Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS >>> Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >>> Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions <http://optarecoolvendor.com> >>> >> >> >> -- >> >> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions >> <http://optarecoolvendor.com><http://optarecoolvendor.com> >> > > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Craig G. (opennms) <cg...@op...> - 2012-07-03 19:07:30
|
Xose, are you also doing the primitive.uri / primitive.url changes to support the new profile? Craig On 03/07/2012 11:33, Xose Ramon Sousa Vazquez wrote: > Hi all. I am developing a module that get the packages to perform the > funcionallity desired, but in the models there are changes in the way > they are instantied so a deeper revision is needed. > I have got the code to obtain the packages and now we are changing the > models, but has a lot of dependences in building the closure. I am > trying to finish it and the publish on the sandbox area better to > perform tests and avoid regression problems. > > > Regards > El 02/07/2012 15:40, Craig Gallen (opennms) escribió: >> Hi Xose, >> >> Duncan from Tigerstripe has replied on bugzilla that we need to >> uncheck the "Run All Rules as Local" >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728 . I have run the >> MPAC model with "Run All Rules as Local" checked and then as >> unchecked to ensure that the property is correctly set in >> tigerstripe.xml. However this does not appear to fix the problem. >> Dependencies are not being generated by the soap plugin. Could you >> run the test in your model and get back to Duncan if it is still the >> issue. >> >> Thanks >> >> Craig >> >> >> >> >> >> On 28/06/2012 08:22, Xose Ramon Sousa Vazquez wrote: >>> I have created the bug >>> Bug 383728 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>has >>> been added to the database >>> >>> Email sent to: >>> |dke...@ci...|,|erd...@ci...|,|tig...@ec...|,|jis...@ci...|,|rcr...@ci...| >>> Excluding: >>> |xr...@op...| >>> >>> >>> >>> Regards >>> El 28/06/2012 9:18, Flauw, Marc escribió: >>>> >>>> Xose, >>>> >>>> Send us the bug pointer and I will escalate it . >>>> >>>> Best regards >>>> >>>> Marc >>>> >>>> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >>>> *Sent:* Thursday, June 28, 2012 9:17 AM >>>> *To:* Craig Gallen (opennms) >>>> *Cc:* 'openoss-devel'; Craig Gallen (entimoss); 'pierre gauthier' >>>> *Subject:* Re: [Openoss-devel] Problems with PM XSD generation >>>> >>>> Hi all. >>>> I have post the problem in the user list as the bug creation >>>> recommends. Nobody answer that so I am going to create the bug. I >>>> have a first version of the workaround but aome problems are >>>> derived in the cast operations in the src_shared classes, so I must >>>> investigate deeper. If this issue is solved I can send you Craig a >>>> preeliminary patch and then check the behaivour of the other >>>> $allxxxx context elements. >>>> >>>> >>>> Regards >>>> El 28/06/2012 6:32, Craig Gallen (opennms) escribió: >>>> >>>> Xose & Marc, >>>> >>>> Is there a plan to complete primitive.url / primitive.uri in >>>> the soap generator. I have support for it in the Java >>>> generators but need the Soap generator working with this >>>> stereotype to test this code. >>>> >>>> Also has a bug been raised against Tigerstripe for the >>>> $allPackage issue ? I'd prefer to fix the problem in >>>> tigerstripe rather than have Xose get a work around because >>>> if this isnt working, its possible other 'get all collections' >>>> of artificates are not working. So this could be a general >>>> problem for the other generators including Cisco's own. >>>> >>>> Xose, have you raised a bug report and if so what is the bug >>>> number? >>>> >>>> Marc, when we have a bug report, can we escalate this directly >>>> to the tigerstripe team because it is a show stopper for us. >>>> >>>> I'm afraid I cannot do any more development until this is fixed. >>>> >>>> Thanks for your help >>>> >>>> Craig >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: >>>> >>>> I am going to test a workaround to see if this could be >>>> supported without change the tigerstripe core. >>>> >>>> Regards >>>> El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: >>>> >>>> Hi, >>>> >>>> So is there a work around or do we have to wait for >>>> Tigerstripe to sort this out. >>>> The old version of tigerstripe (6.9.xxx) is no longer >>>> available to download. >>>> >>>> Craig >>>> >>>> On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >>>> >>>> Thanks Craig. >>>> I have performed some test and I can see an error >>>> in the Default Velocity context contents. When the >>>> $allPackage variable is used in the >>>> dependencyAnalyzer.vm template, it is expected that >>>> all artifacts, including the dependences, are >>>> included in that collection. In my tests I've got >>>> this behaivour: >>>> >>>> Old version of tigerstripe( Tigerstripe Core >>>> (Incubation) 0.6.935.201102010903 >>>> org.eclipse.tigerstripe.base.feature.group) >>>> %%%Calculate the dependencies/closure with >>>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>>> org.tmforum.tip.resource.trouble(428889018), >>>> org.tmforum.tip.resource(240211633), >>>> org.tmforum.tip.cbe.perf(1039318676), >>>> org.tmforum.tip.common.notifications(23492680), >>>> org.tmforum.tip.resource.res(1133197283), >>>> org.tmforum.tip.cbe.root(1039387789), >>>> org.tmforum.tip(-660924437), >>>> org.tmforum.tip.cbe.root._char(-1449023596), >>>> org.tmforum(1644248382), org(110308), >>>> org.tmforum.tip.common(442435918), >>>> org.tmforum.tip.cbe.party(-2140978021), >>>> org.tmforum.tip.cbe.problem(292836116), >>>> org.tmforum.tip.cbe.root.tip.fmk(693071952), >>>> org.tmforum.tip.internal.filter(-1708340282), >>>> org.tmforum.tip.internal.extensibility(-1665414181), org.tmforum.tip.internal(1151687008), >>>> org.tmforum.tip.cbe.root.tip(1325885370), >>>> org.tmforum.tip.internal.notifications(-1680981798), org.tmforum.tip.common.exceptions(234099364), >>>> org.tmforum.tip.cbe.party.role(1514413545), >>>> org.tmforum.tip.internal.entity(-1732123599), >>>> org.tmforum.tip.resource.res.tip(-1716701168), >>>> org.tmforum.tip.internal.exceptions(-367434926), >>>> org.tmforum.tip.cbe(1681757027), >>>> org.tmforum.tip.internal.iterator(866200892), >>>> org.tmforum.tip.resource.res.tip.nrb(290014272)] >>>> [2012-06-26 10:21:29.996+0200] >>>> >>>> New version og tigerstripe( Tigerstripe Core >>>> (Incubation) 0.7.0.201206181258 >>>> org.eclipse.tigerstripe.base.feature.group): >>>> %%%Calculate the dependencies/closure with >>>> [org.tmforum.tip.resource.trouble.alarm(370509597), >>>> org.tmforum.tip.resource.trouble(428889018), >>>> org.tmforum.tip.resource(240211633)] [2012-06-26 >>>> 10:28:54.989+0200] >>>> >>>> So it seems that this is root cause for the missed >>>> files. >>>> I will create a bug in Tigerstripe. >>>> >>>> Regards >>>> >>>> El 25/06/2012 18:35, Craig Gallen (entimoss) escribió: >>>> >>>> Hi >>>> From eclipse, Soap generator subversion; >>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>> Revision 3453 >>>> (last change revision 3444 last commit author xrsousa) >>>> >>>> Craig >>>> >>>> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >>>> >>>> Hi Craig, when you talk about the updated Soap >>>> Plugin, which version (in svn url) are using?, >>>> because the two first issues seems to be solved in >>>> the trunk with the other Tigerstripe version. >>>> >>>> >>>> >>>> >>>> Regards >>>> El 25/06/2012 16:54, Craig Gallen (entimoss) escribió: >>>> >>>> Hi Xose, >>>> >>>> I just updated my tigerstripe to the latest release >>>> 0.7.0.20120618258 but Ialso updated the Soap >>>> plug-in and have found multiple problems but I am >>>> not sure if they are all related to the tigerstripe >>>> upgrade or to the current state of the soap plugin. >>>> Could you build the RAM project and check the >>>> generated XSD's to see the problem. >>>> >>>> 1. when you build the RAM project there is a >>>> problem with model closure. None of the Dependency >>>> XSD's get generated in the RAM_Model project >>>> >>>> 2. TrackingRecordResultWithIterator referenced as >>>> 'problem:TrackingRecordResultWithIterator' in >>>> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd >>>> is never generated. >>>> >>>> 3. Tigerstripe 0.7.0.20120618258. handles >>>> primitive.string differently and generates type >>>> 'String' instead of 'java.lang.String' this results >>>> in type :String instead of xsd:string. I did a >>>> quick fix given in the following patch adding >>>> || >>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>> >>>> to >>>> || >>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>> this means that old and new versions of tigerstipe >>>> will work >>>> >>>> There is a patch below but havent checked this in >>>> because I was not sure that else you were doing to >>>> the Soap plugin >>>> >>>> Craig >>>> >>>> >>>> >>>> ### Eclipse Workspace Patch 1.0 >>>> #P TIP_Soap_Generator >>>> Index: >>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>> =================================================================== >>>> --- >>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>> (revision 3453) >>>> +++ >>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>> (working copy) >>>> @@ -510,8 +510,8 @@ >>>> */ >>>> if (refType.isPrimitive() >>>> || >>>> refType.getPackage().equalsIgnoreCase("primitive") >>>> - || >>>> "java.lang.String".equalsIgnoreCase(refType >>>> - .getFullyQualifiedName())) { >>>> + || >>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>> + || >>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>> { // tigerstripe 1.7.0 now generates String and not >>>> java.lang.String >>>> PluginLog.logDebug("\'" + refTypeFullName >>>> + "\' is a primitive type in >>>> current TIP profile."); >>>> type = >>>> mapPrimitivesToXsdType(refType.getName(), >>>> isArray(refType), >>>> @@ -519,7 +519,7 @@ >>>> } >>>> >>>> /** >>>> - * Map datatyeps and enumerations >>>> + * Map datatypes and enumerations >>>> */ >>>> // if (refType.isDatatype() || >>>> refType.isEnum() >>>> else if (isDatatype(refType) || >>>> isEnumeration(refType)) { >>>> Index: >>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>> =================================================================== >>>> --- >>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>> (revision 3453) >>>> +++ >>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>> (working copy) >>>> @@ -170,8 +170,9 @@ >>>> private void addReferencedPackage(IType type) { >>>> >>>> if (type.isPrimitive() >>>> - || >>>> "primitive".equalsIgnoreCase(type.getPackage()) || >>>> - >>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) >>>> { >>>> + || >>>> "primitive".equalsIgnoreCase(type.getPackage()) >>>> + || >>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>>> + || >>>> "String".equalsIgnoreCase(type.getFullyQualifiedName())) >>>> { // tigerstripe 1.7.0 now generates String and not >>>> java.lang.String >>>> //will map objectName to >>>> EntityIdentifier or ArrayOfEntityIdentifier >>>> if >>>> ("objectName".equalsIgnoreCase(type.getName())){ >>>> PluginLog.logDebug("type \'" + type >>>> @@ -378,8 +379,8 @@ >>>> */ >>>> if (refType.isPrimitive() >>>> || >>>> refType.getPackage().equalsIgnoreCase("primitive") >>>> - || >>>> "java.lang.String".equalsIgnoreCase(refType >>>> - .getFullyQualifiedName())) { >>>> + || >>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>> + || >>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>> { // tigerstripe 1.7.0 now generates String and not >>>> java.lang.String >>>> PluginLog.logDebug("\'" + typeName >>>> + "\' is a primitive type in >>>> current TIP profile."); >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>>> >>>> Hi all. I think that I have found the error and I >>>> will try to fix it as soon as possible. There are >>>> some related issues, one error in the codification >>>> of a method and a forgetted evaluation of filtering >>>> in the velocity template and also a case related >>>> with primitive type filter not supported in the >>>> build of the closure outside the interfaces. >>>> >>>> In the interfaces build the search is performed as >>>> follows(this works fine as reported Marc): >>>> >>>> if >>>> ("objectName".equalsIgnoreCase(argType.getName())) { >>>> /* >>>> * This data type >>>> 'objectName' defines the protocol >>>> * neutral unique name of >>>> an object. This data type will >>>> * be replaced by the >>>> generators by an EntityIdentifier >>>> */ >>>> String pkg = PluginConstants >>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>>> if >>>> (!this.map.containsKey(pkg)) { >>>> // >>>> // New package - add >>>> new pkg=prefix mapping >>>> // assignment >>>> // >>>> String prefix = >>>> XmlSchemaHelpers.generateXmlPrefix( >>>> pkg, this.map); >>>> this.map.put(pkg, prefix); >>>> } >>>> } else if >>>> ("filter".equalsIgnoreCase(argType.getName())) { >>>> /* >>>> * This data type 'filter'. >>>> This data type will >>>> * be replaced by the >>>> generator to >>>> */ >>>> String pkg = PluginConstants >>>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >>>> if >>>> (!this.map.containsKey(pkg)) { >>>> // >>>> // New package - add >>>> new pkg=prefix mapping >>>> // assignment >>>> // >>>> String prefix = >>>> XmlSchemaHelpers.generateXmlPrefix( >>>> pkg, this.map); >>>> this.map.put(pkg, prefix); >>>> } >>>> } else if >>>> (XmlSchemaHelpers.isUnbounded(argType)) { >>>> String pkg = PluginConstants >>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >>>> if >>>> (!this.map.containsKey(pkg)) { >>>> // >>>> // New package - add >>>> new pkg=prefix mapping >>>> // assignment >>>> // >>>> String prefix = >>>> XmlSchemaHelpers.generateXmlPrefix( >>>> pkg, this.map); >>>> this.map.put(pkg, prefix); >>>> } >>>> } else { >>>> // XSD default namespace is >>>> enough >>>> } >>>> >>>> and in the build of the closure we have got (this >>>> fails as reported Craig): >>>> >>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>> PluginLog.logDebug("type \'" + type >>>> + "\' is an array of primitive."); >>>> addReferencedPackage(PluginConstants >>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >>>> }else if >>>> (XmlSchemaHelpers.isUnbounded(type)){ >>>> //will map to array of primitive >>>> addReferencedPackage(PluginConstants >>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >>>> } else { >>>> //normal primtive like xsd:int >>>> } >>>> >>>> so the filtering never is considered. >>>> >>>> I will perform clean tests because was very >>>> difficult to find the real cause of the problem, >>>> the log file is not very clear in debug scenarios ( >>>> a lot of similar log text, no log from the >>>> templates and also cannot put the line number in >>>> the log file (tigerstripe issue)) and these >>>> problems have delayed my response. >>>> If the test go ok I will check out the changes to >>>> the trunk >>>> >>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>> >>>> Best regards >>>> >>>> >>>> El 01/06/2012 16:58, Craig Gallen escribió: >>>> >>>> Hi, >>>> >>>> >>>> >>>> I agree it is defined in internal_filter.xsd but it doesn't seem to be >>>> >>>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >>>> >>>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >>>> >>>> shows an error. >>>> >>>> >>>> >>>> I think Xose is looking into it >>>> >>>> >>>> >>>> Craig >>>> >>>> >>>> >>>> -----Original Message----- >>>> >>>> From: Flauw, Marc [mailto:Mar...@hp...] >>>> >>>> Sent: 01 June 2012 10:25 >>>> >>>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >>>> >>>> gauthier >>>> >>>> Subject: RE: Problems with PM XSD generation >>>> >>>> >>>> >>>> Craig, >>>> >>>> >>>> >>>> There is one same filter in the getReosurceAlarms operation, filter >>>> >>>> argument. >>>> >>>> The XPathFilter is defined in the internal_filter.xsd >>>> >>>> >>>> >>>> Best regards >>>> >>>> >>>> >>>> Marc >>>> >>>> >>>> >>>> -----Original Message----- >>>> >>>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >>>> >>>> Gallen (opennms) >>>> >>>> Sent: Thursday, May 31, 2012 11:58 PM >>>> >>>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >>>> >>>> Subject: Problems with PM XSD generation >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> I have been testing the TIP_PM_Col project model and have found that the >>>> >>>> dep_cbe_perf_spec.xsd (attached) file is generated with errors >>>> >>>> >>>> >>>> in line 62 we have >>>> >>>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >>>> >>>> minOccurs="0" maxOccurs="1"> >>>> >>>> >>>> >>>> filter:XPathQueryFilter is not defined and if you open the file in eclipse >>>> >>>> it reports this error as: >>>> >>>> >>>> >>>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >>>> >>>> 'element'. Recorded reason: >>>> >>>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >>>> >>>> the prefix 'filter' is not >>>> >>>> declared'. >>>> >>>> >>>> >>>> Is this a known problem or a new bug? >>>> >>>> >>>> >>>> Craig >>>> >>>> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>> Technologies, Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions <http://optarecoolvendor.com> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>> Technologies, Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions <http://optarecoolvendor.com> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>> Technologies, Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions <http://optarecoolvendor.com> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >>>> Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions <http://optarecoolvendor.com> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions <http://optarecoolvendor.com> >>>> >>> >>> >>> -- >>> >>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>> www.optaresolutions.com >>> <http://www.optaresolutions.com> >>> Optare Solutions >>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>> >> >> > > > -- > > *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D > T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 > www.optaresolutions.com > <http://www.optaresolutions.com> > Optare Solutions > <http://optarecoolvendor.com><http://optarecoolvendor.com> > |
|
From: Xose R. S. V. <xr...@op...> - 2012-07-03 22:52:56
|
No, because it seems that the allPackages was a blocking issue. I am finishing the tests and after that I can follow with that. Regards El 03/07/2012 21:07, Craig Gallen (opennms) escribió: > Xose, > are you also doing the primitive.uri / primitive.url changes to > support the new profile? > Craig > > > On 03/07/2012 11:33, Xose Ramon Sousa Vazquez wrote: >> Hi all. I am developing a module that get the packages to perform >> the funcionallity desired, but in the models there are changes in the >> way they are instantied so a deeper revision is needed. >> I have got the code to obtain the packages and now we are changing >> the models, but has a lot of dependences in building the closure. I >> am trying to finish it and the publish on the sandbox area better to >> perform tests and avoid regression problems. >> >> >> Regards >> El 02/07/2012 15:40, Craig Gallen (opennms) escribió: >>> Hi Xose, >>> >>> Duncan from Tigerstripe has replied on bugzilla that we need to >>> uncheck the "Run All Rules as Local" >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728 . I have run >>> the MPAC model with "Run All Rules as Local" checked and then as >>> unchecked to ensure that the property is correctly set in >>> tigerstripe.xml. However this does not appear to fix the problem. >>> Dependencies are not being generated by the soap plugin. Could you >>> run the test in your model and get back to Duncan if it is still the >>> issue. >>> >>> Thanks >>> >>> Craig >>> >>> >>> >>> >>> >>> On 28/06/2012 08:22, Xose Ramon Sousa Vazquez wrote: >>>> I have created the bug >>>> Bug 383728 >>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>has been >>>> added to the database >>>> >>>> Email sent to: >>>> |dke...@ci...|,|erd...@ci...|,|tig...@ec...|,|jis...@ci...|,|rcr...@ci...| >>>> Excluding: >>>> |xr...@op...| >>>> >>>> >>>> >>>> Regards >>>> El 28/06/2012 9:18, Flauw, Marc escribió: >>>>> >>>>> Xose, >>>>> >>>>> Send us the bug pointer and I will escalate it . >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >>>>> *Sent:* Thursday, June 28, 2012 9:17 AM >>>>> *To:* Craig Gallen (opennms) >>>>> *Cc:* 'openoss-devel'; Craig Gallen (entimoss); 'pierre gauthier' >>>>> *Subject:* Re: [Openoss-devel] Problems with PM XSD generation >>>>> >>>>> Hi all. >>>>> I have post the problem in the user list as the bug creation >>>>> recommends. Nobody answer that so I am going to create the bug. I >>>>> have a first version of the workaround but aome problems are >>>>> derived in the cast operations in the src_shared classes, so I >>>>> must investigate deeper. If this issue is solved I can send you >>>>> Craig a preeliminary patch and then check the behaivour of the >>>>> other $allxxxx context elements. >>>>> >>>>> >>>>> Regards >>>>> El 28/06/2012 6:32, Craig Gallen (opennms) escribió: >>>>> >>>>> Xose & Marc, >>>>> >>>>> Is there a plan to complete primitive.url / primitive.uri in >>>>> the soap generator. I have support for it in the Java >>>>> generators but need the Soap generator working with this >>>>> stereotype to test this code. >>>>> >>>>> Also has a bug been raised against Tigerstripe for the >>>>> $allPackage issue ? I'd prefer to fix the problem in >>>>> tigerstripe rather than have Xose get a work around because >>>>> if this isnt working, its possible other 'get all collections' >>>>> of artificates are not working. So this could be a general >>>>> problem for the other generators including Cisco's own. >>>>> >>>>> Xose, have you raised a bug report and if so what is the bug >>>>> number? >>>>> >>>>> Marc, when we have a bug report, can we escalate this directly >>>>> to the tigerstripe team because it is a show stopper for us. >>>>> >>>>> I'm afraid I cannot do any more development until this is fixed. >>>>> >>>>> Thanks for your help >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> I am going to test a workaround to see if this could be >>>>> supported without change the tigerstripe core. >>>>> >>>>> Regards >>>>> El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: >>>>> >>>>> Hi, >>>>> >>>>> So is there a work around or do we have to wait for >>>>> Tigerstripe to sort this out. >>>>> The old version of tigerstripe (6.9.xxx) is no longer >>>>> available to download. >>>>> >>>>> Craig >>>>> >>>>> On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> Thanks Craig. >>>>> I have performed some test and I can see an error >>>>> in the Default Velocity context contents. When the >>>>> $allPackage variable is used in the >>>>> dependencyAnalyzer.vm template, it is expected >>>>> that all artifacts, including the dependences, are >>>>> included in that collection. In my tests I've got >>>>> this behaivour: >>>>> >>>>> Old version of tigerstripe( Tigerstripe Core >>>>> (Incubation) 0.6.935.201102010903 >>>>> org.eclipse.tigerstripe.base.feature.group) >>>>> %%%Calculate the dependencies/closure with >>>>> [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), >>>>> org.tmforum.tip.resource(240211633), >>>>> org.tmforum.tip.cbe.perf(1039318676), >>>>> org.tmforum.tip.common.notifications(23492680), >>>>> org.tmforum.tip.resource.res(1133197283), >>>>> org.tmforum.tip.cbe.root(1039387789), >>>>> org.tmforum.tip(-660924437), >>>>> org.tmforum.tip.cbe.root._char(-1449023596), >>>>> org.tmforum(1644248382), org(110308), >>>>> org.tmforum.tip.common(442435918), >>>>> org.tmforum.tip.cbe.party(-2140978021), >>>>> org.tmforum.tip.cbe.problem(292836116), >>>>> org.tmforum.tip.cbe.root.tip.fmk(693071952), >>>>> org.tmforum.tip.internal.filter(-1708340282), >>>>> org.tmforum.tip.internal.extensibility(-1665414181), >>>>> org.tmforum.tip.internal(1151687008), >>>>> org.tmforum.tip.cbe.root.tip(1325885370), >>>>> org.tmforum.tip.internal.notifications(-1680981798), >>>>> org.tmforum.tip.common.exceptions(234099364), >>>>> org.tmforum.tip.cbe.party.role(1514413545), >>>>> org.tmforum.tip.internal.entity(-1732123599), >>>>> org.tmforum.tip.resource.res.tip(-1716701168), >>>>> org.tmforum.tip.internal.exceptions(-367434926), >>>>> org.tmforum.tip.cbe(1681757027), >>>>> org.tmforum.tip.internal.iterator(866200892), >>>>> org.tmforum.tip.resource.res.tip.nrb(290014272)] >>>>> [2012-06-26 10:21:29.996+0200] >>>>> >>>>> New version og tigerstripe( Tigerstripe Core >>>>> (Incubation) 0.7.0.201206181258 >>>>> org.eclipse.tigerstripe.base.feature.group): >>>>> %%%Calculate the dependencies/closure with >>>>> [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), >>>>> org.tmforum.tip.resource(240211633)] [2012-06-26 >>>>> 10:28:54.989+0200] >>>>> >>>>> So it seems that this is root cause for the missed >>>>> files. >>>>> I will create a bug in Tigerstripe. >>>>> >>>>> Regards >>>>> >>>>> El 25/06/2012 18:35, Craig Gallen (entimoss) >>>>> escribió: >>>>> >>>>> Hi >>>>> From eclipse, Soap generator subversion; >>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>>> Revision 3453 >>>>> (last change revision 3444 last commit author xrsousa) >>>>> >>>>> Craig >>>>> >>>>> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> Hi Craig, when you talk about the updated Soap >>>>> Plugin, which version (in svn url) are using?, >>>>> because the two first issues seems to be solved in >>>>> the trunk with the other Tigerstripe version. >>>>> >>>>> >>>>> >>>>> >>>>> Regards >>>>> El 25/06/2012 16:54, Craig Gallen (entimoss) >>>>> escribió: >>>>> >>>>> Hi Xose, >>>>> >>>>> I just updated my tigerstripe to the latest >>>>> release 0.7.0.20120618258 but Ialso updated the >>>>> Soap plug-in and have found multiple problems but >>>>> I am not sure if they are all related to the >>>>> tigerstripe upgrade or to the current state of the >>>>> soap plugin. Could you build the RAM project and >>>>> check the generated XSD's to see the problem. >>>>> >>>>> 1. when you build the RAM project there is a >>>>> problem with model closure. None of the >>>>> Dependency XSD's get generated in the RAM_Model >>>>> project >>>>> >>>>> 2. TrackingRecordResultWithIterator referenced as >>>>> 'problem:TrackingRecordResultWithIterator' in >>>>> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd >>>>> is never generated. >>>>> >>>>> 3. Tigerstripe 0.7.0.20120618258. handles >>>>> primitive.string differently and generates type >>>>> 'String' instead of 'java.lang.String' this >>>>> results in type :String instead of xsd:string. I >>>>> did a quick fix given in the following patch adding >>>>> || >>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>> >>>>> to >>>>> || >>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> this means that old and new versions of tigerstipe >>>>> will work >>>>> >>>>> There is a patch below but havent checked this in >>>>> because I was not sure that else you were doing to >>>>> the Soap plugin >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> ### Eclipse Workspace Patch 1.0 >>>>> #P TIP_Soap_Generator >>>>> Index: >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> =================================================================== >>>>> --- >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> (revision 3453) >>>>> +++ >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> (working copy) >>>>> @@ -510,8 +510,8 @@ >>>>> */ >>>>> if (refType.isPrimitive() >>>>> || >>>>> refType.getPackage().equalsIgnoreCase("primitive") >>>>> - || >>>>> "java.lang.String".equalsIgnoreCase(refType >>>>> - .getFullyQualifiedName())) { >>>>> + || >>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> + || >>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>> { // tigerstripe 1.7.0 now generates String and >>>>> not java.lang.String >>>>> PluginLog.logDebug("\'" + refTypeFullName >>>>> + "\' is a primitive type in >>>>> current TIP profile."); >>>>> type = >>>>> mapPrimitivesToXsdType(refType.getName(), >>>>> isArray(refType), >>>>> @@ -519,7 +519,7 @@ >>>>> } >>>>> >>>>> /** >>>>> - * Map datatyeps and enumerations >>>>> + * Map datatypes and enumerations >>>>> */ >>>>> // if (refType.isDatatype() || >>>>> refType.isEnum() >>>>> else if (isDatatype(refType) || >>>>> isEnumeration(refType)) { >>>>> Index: >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> =================================================================== >>>>> --- >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> (revision 3453) >>>>> +++ >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> (working copy) >>>>> @@ -170,8 +170,9 @@ >>>>> private void addReferencedPackage(IType type) { >>>>> >>>>> if (type.isPrimitive() >>>>> - || >>>>> "primitive".equalsIgnoreCase(type.getPackage()) || >>>>> - >>>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) >>>>> { >>>>> + || >>>>> "primitive".equalsIgnoreCase(type.getPackage()) >>>>> + || >>>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>>>> + || >>>>> "String".equalsIgnoreCase(type.getFullyQualifiedName())) >>>>> { // tigerstripe 1.7.0 now generates String and >>>>> not java.lang.String >>>>> //will map objectName to >>>>> EntityIdentifier or ArrayOfEntityIdentifier >>>>> if >>>>> ("objectName".equalsIgnoreCase(type.getName())){ >>>>> PluginLog.logDebug("type \'" + type >>>>> @@ -378,8 +379,8 @@ >>>>> */ >>>>> if (refType.isPrimitive() >>>>> || >>>>> refType.getPackage().equalsIgnoreCase("primitive") >>>>> - || >>>>> "java.lang.String".equalsIgnoreCase(refType >>>>> - .getFullyQualifiedName())) { >>>>> + || >>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> + || >>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>> { // tigerstripe 1.7.0 now generates String and >>>>> not java.lang.String >>>>> PluginLog.logDebug("\'" + typeName >>>>> + "\' is a primitive type in >>>>> current TIP profile."); >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> Hi all. I think that I have found the error and I >>>>> will try to fix it as soon as possible. There are >>>>> some related issues, one error in the codification >>>>> of a method and a forgetted evaluation of >>>>> filtering in the velocity template and also a case >>>>> related with primitive type filter not supported >>>>> in the build of the closure outside the interfaces. >>>>> >>>>> In the interfaces build the search is performed as >>>>> follows(this works fine as reported Marc): >>>>> >>>>> if >>>>> ("objectName".equalsIgnoreCase(argType.getName())) { >>>>> /* >>>>> * This data type >>>>> 'objectName' defines the protocol >>>>> * neutral unique name of >>>>> an object. This data type will >>>>> * be replaced by the >>>>> generators by an EntityIdentifier >>>>> */ >>>>> String pkg = PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>>>> if >>>>> (!this.map.containsKey(pkg)) { >>>>> // >>>>> // New package - add >>>>> new pkg=prefix mapping >>>>> // assignment >>>>> // >>>>> String prefix = >>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>> pkg, this.map); >>>>> this.map.put(pkg, prefix); >>>>> } >>>>> } else if >>>>> ("filter".equalsIgnoreCase(argType.getName())) { >>>>> /* >>>>> * This data type >>>>> 'filter'. This data type will >>>>> * be replaced by the >>>>> generator to >>>>> */ >>>>> String pkg = PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >>>>> if >>>>> (!this.map.containsKey(pkg)) { >>>>> // >>>>> // New package - add >>>>> new pkg=prefix mapping >>>>> // assignment >>>>> // >>>>> String prefix = >>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>> pkg, this.map); >>>>> this.map.put(pkg, prefix); >>>>> } >>>>> } else if >>>>> (XmlSchemaHelpers.isUnbounded(argType)) { >>>>> String pkg = PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >>>>> if >>>>> (!this.map.containsKey(pkg)) { >>>>> // >>>>> // New package - add >>>>> new pkg=prefix mapping >>>>> // assignment >>>>> // >>>>> String prefix = >>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>> pkg, this.map); >>>>> this.map.put(pkg, prefix); >>>>> } >>>>> } else { >>>>> // XSD default namespace >>>>> is enough >>>>> } >>>>> >>>>> and in the build of the closure we have got (this >>>>> fails as reported Craig): >>>>> >>>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>>> PluginLog.logDebug("type \'" + type >>>>> + "\' is an array of primitive."); >>>>> addReferencedPackage(PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >>>>> }else if >>>>> (XmlSchemaHelpers.isUnbounded(type)){ >>>>> //will map to array of primitive >>>>> addReferencedPackage(PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >>>>> } else { >>>>> //normal primtive like xsd:int >>>>> } >>>>> >>>>> so the filtering never is considered. >>>>> >>>>> I will perform clean tests because was very >>>>> difficult to find the real cause of the problem, >>>>> the log file is not very clear in debug scenarios >>>>> ( a lot of similar log text, no log from the >>>>> templates and also cannot put the line number in >>>>> the log file (tigerstripe issue)) and these >>>>> problems have delayed my response. >>>>> If the test go ok I will check out the changes to >>>>> the trunk >>>>> >>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>>> >>>>> Best regards >>>>> >>>>> >>>>> El 01/06/2012 16:58, Craig Gallen escribió: >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> I agree it is defined in internal_filter.xsd but it doesn't seem to be >>>>> >>>>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >>>>> >>>>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >>>>> >>>>> shows an error. >>>>> >>>>> >>>>> >>>>> I think Xose is looking into it >>>>> >>>>> >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: Flauw, Marc [mailto:Mar...@hp...] >>>>> >>>>> Sent: 01 June 2012 10:25 >>>>> >>>>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >>>>> >>>>> gauthier >>>>> >>>>> Subject: RE: Problems with PM XSD generation >>>>> >>>>> >>>>> >>>>> Craig, >>>>> >>>>> >>>>> >>>>> There is one same filter in the getReosurceAlarms operation, filter >>>>> >>>>> argument. >>>>> >>>>> The XPathFilter is defined in the internal_filter.xsd >>>>> >>>>> >>>>> >>>>> Best regards >>>>> >>>>> >>>>> >>>>> Marc >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >>>>> >>>>> Gallen (opennms) >>>>> >>>>> Sent: Thursday, May 31, 2012 11:58 PM >>>>> >>>>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >>>>> >>>>> Subject: Problems with PM XSD generation >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> I have been testing the TIP_PM_Col project model and have found that the >>>>> >>>>> dep_cbe_perf_spec.xsd (attached) file is generated with errors >>>>> >>>>> >>>>> >>>>> in line 62 we have >>>>> >>>>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >>>>> >>>>> minOccurs="0" maxOccurs="1"> >>>>> >>>>> >>>>> >>>>> filter:XPathQueryFilter is not defined and if you open the file in eclipse >>>>> >>>>> it reports this error as: >>>>> >>>>> >>>>> >>>>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >>>>> >>>>> 'element'. Recorded reason: >>>>> >>>>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >>>>> >>>>> the prefix 'filter' is not >>>>> >>>>> declared'. >>>>> >>>>> >>>>> >>>>> Is this a known problem or a new bug? >>>>> >>>>> >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>>> Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>>> Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>>> Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >>>>> Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions >>>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>>> >>> >>> >> >> >> -- >> >> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions >> <http://optarecoolvendor.com><http://optarecoolvendor.com> >> > > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
|
From: Xose R. S. V. <xr...@op...> - 2012-07-04 07:30:22
|
I have developed a workaround for solve the bug in tigerstripe, you can download from: https://openoss.svn.sourceforge.net/svnroot/openoss/tip/sandbox/xrsousa/SoapPluginBugAllPackages/TIP_Soap_Generator Please send me feedback about that Regards El 03/07/2012 21:07, Craig Gallen (opennms) escribió: > Xose, > are you also doing the primitive.uri / primitive.url changes to > support the new profile? > Craig > > > On 03/07/2012 11:33, Xose Ramon Sousa Vazquez wrote: >> Hi all. I am developing a module that get the packages to perform >> the funcionallity desired, but in the models there are changes in the >> way they are instantied so a deeper revision is needed. >> I have got the code to obtain the packages and now we are changing >> the models, but has a lot of dependences in building the closure. I >> am trying to finish it and the publish on the sandbox area better to >> perform tests and avoid regression problems. >> >> >> Regards >> El 02/07/2012 15:40, Craig Gallen (opennms) escribió: >>> Hi Xose, >>> >>> Duncan from Tigerstripe has replied on bugzilla that we need to >>> uncheck the "Run All Rules as Local" >>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728 . I have run >>> the MPAC model with "Run All Rules as Local" checked and then as >>> unchecked to ensure that the property is correctly set in >>> tigerstripe.xml. However this does not appear to fix the problem. >>> Dependencies are not being generated by the soap plugin. Could you >>> run the test in your model and get back to Duncan if it is still the >>> issue. >>> >>> Thanks >>> >>> Craig >>> >>> >>> >>> >>> >>> On 28/06/2012 08:22, Xose Ramon Sousa Vazquez wrote: >>>> I have created the bug >>>> Bug 383728 >>>> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=383728>has been >>>> added to the database >>>> >>>> Email sent to: >>>> |dke...@ci...|,|erd...@ci...|,|tig...@ec...|,|jis...@ci...|,|rcr...@ci...| >>>> Excluding: >>>> |xr...@op...| >>>> >>>> >>>> >>>> Regards >>>> El 28/06/2012 9:18, Flauw, Marc escribió: >>>>> >>>>> Xose, >>>>> >>>>> Send us the bug pointer and I will escalate it . >>>>> >>>>> Best regards >>>>> >>>>> Marc >>>>> >>>>> *From:*Xose Ramon Sousa Vazquez [mailto:xr...@op...] >>>>> *Sent:* Thursday, June 28, 2012 9:17 AM >>>>> *To:* Craig Gallen (opennms) >>>>> *Cc:* 'openoss-devel'; Craig Gallen (entimoss); 'pierre gauthier' >>>>> *Subject:* Re: [Openoss-devel] Problems with PM XSD generation >>>>> >>>>> Hi all. >>>>> I have post the problem in the user list as the bug creation >>>>> recommends. Nobody answer that so I am going to create the bug. I >>>>> have a first version of the workaround but aome problems are >>>>> derived in the cast operations in the src_shared classes, so I >>>>> must investigate deeper. If this issue is solved I can send you >>>>> Craig a preeliminary patch and then check the behaivour of the >>>>> other $allxxxx context elements. >>>>> >>>>> >>>>> Regards >>>>> El 28/06/2012 6:32, Craig Gallen (opennms) escribió: >>>>> >>>>> Xose & Marc, >>>>> >>>>> Is there a plan to complete primitive.url / primitive.uri in >>>>> the soap generator. I have support for it in the Java >>>>> generators but need the Soap generator working with this >>>>> stereotype to test this code. >>>>> >>>>> Also has a bug been raised against Tigerstripe for the >>>>> $allPackage issue ? I'd prefer to fix the problem in >>>>> tigerstripe rather than have Xose get a work around because >>>>> if this isnt working, its possible other 'get all collections' >>>>> of artificates are not working. So this could be a general >>>>> problem for the other generators including Cisco's own. >>>>> >>>>> Xose, have you raised a bug report and if so what is the bug >>>>> number? >>>>> >>>>> Marc, when we have a bug report, can we escalate this directly >>>>> to the tigerstripe team because it is a show stopper for us. >>>>> >>>>> I'm afraid I cannot do any more development until this is fixed. >>>>> >>>>> Thanks for your help >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 27/06/2012 10:01, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> I am going to test a workaround to see if this could be >>>>> supported without change the tigerstripe core. >>>>> >>>>> Regards >>>>> El 26/06/2012 17:03, Craig Gallen (entimoss) escribió: >>>>> >>>>> Hi, >>>>> >>>>> So is there a work around or do we have to wait for >>>>> Tigerstripe to sort this out. >>>>> The old version of tigerstripe (6.9.xxx) is no longer >>>>> available to download. >>>>> >>>>> Craig >>>>> >>>>> On 26/06/2012 09:39, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> Thanks Craig. >>>>> I have performed some test and I can see an error >>>>> in the Default Velocity context contents. When the >>>>> $allPackage variable is used in the >>>>> dependencyAnalyzer.vm template, it is expected >>>>> that all artifacts, including the dependences, are >>>>> included in that collection. In my tests I've got >>>>> this behaivour: >>>>> >>>>> Old version of tigerstripe( Tigerstripe Core >>>>> (Incubation) 0.6.935.201102010903 >>>>> org.eclipse.tigerstripe.base.feature.group) >>>>> %%%Calculate the dependencies/closure with >>>>> [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), >>>>> org.tmforum.tip.resource(240211633), >>>>> org.tmforum.tip.cbe.perf(1039318676), >>>>> org.tmforum.tip.common.notifications(23492680), >>>>> org.tmforum.tip.resource.res(1133197283), >>>>> org.tmforum.tip.cbe.root(1039387789), >>>>> org.tmforum.tip(-660924437), >>>>> org.tmforum.tip.cbe.root._char(-1449023596), >>>>> org.tmforum(1644248382), org(110308), >>>>> org.tmforum.tip.common(442435918), >>>>> org.tmforum.tip.cbe.party(-2140978021), >>>>> org.tmforum.tip.cbe.problem(292836116), >>>>> org.tmforum.tip.cbe.root.tip.fmk(693071952), >>>>> org.tmforum.tip.internal.filter(-1708340282), >>>>> org.tmforum.tip.internal.extensibility(-1665414181), >>>>> org.tmforum.tip.internal(1151687008), >>>>> org.tmforum.tip.cbe.root.tip(1325885370), >>>>> org.tmforum.tip.internal.notifications(-1680981798), >>>>> org.tmforum.tip.common.exceptions(234099364), >>>>> org.tmforum.tip.cbe.party.role(1514413545), >>>>> org.tmforum.tip.internal.entity(-1732123599), >>>>> org.tmforum.tip.resource.res.tip(-1716701168), >>>>> org.tmforum.tip.internal.exceptions(-367434926), >>>>> org.tmforum.tip.cbe(1681757027), >>>>> org.tmforum.tip.internal.iterator(866200892), >>>>> org.tmforum.tip.resource.res.tip.nrb(290014272)] >>>>> [2012-06-26 10:21:29.996+0200] >>>>> >>>>> New version og tigerstripe( Tigerstripe Core >>>>> (Incubation) 0.7.0.201206181258 >>>>> org.eclipse.tigerstripe.base.feature.group): >>>>> %%%Calculate the dependencies/closure with >>>>> [org.tmforum.tip.resource.trouble.alarm(370509597), org.tmforum.tip.resource.trouble(428889018), >>>>> org.tmforum.tip.resource(240211633)] [2012-06-26 >>>>> 10:28:54.989+0200] >>>>> >>>>> So it seems that this is root cause for the missed >>>>> files. >>>>> I will create a bug in Tigerstripe. >>>>> >>>>> Regards >>>>> >>>>> El 25/06/2012 18:35, Craig Gallen (entimoss) >>>>> escribió: >>>>> >>>>> Hi >>>>> From eclipse, Soap generator subversion; >>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>>> Revision 3453 >>>>> (last change revision 3444 last commit author xrsousa) >>>>> >>>>> Craig >>>>> >>>>> On 25/06/2012 15:57, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> Hi Craig, when you talk about the updated Soap >>>>> Plugin, which version (in svn url) are using?, >>>>> because the two first issues seems to be solved in >>>>> the trunk with the other Tigerstripe version. >>>>> >>>>> >>>>> >>>>> >>>>> Regards >>>>> El 25/06/2012 16:54, Craig Gallen (entimoss) >>>>> escribió: >>>>> >>>>> Hi Xose, >>>>> >>>>> I just updated my tigerstripe to the latest >>>>> release 0.7.0.20120618258 but Ialso updated the >>>>> Soap plug-in and have found multiple problems but >>>>> I am not sure if they are all related to the >>>>> tigerstripe upgrade or to the current state of the >>>>> soap plugin. Could you build the RAM project and >>>>> check the generated XSD's to see the problem. >>>>> >>>>> 1. when you build the RAM project there is a >>>>> problem with model closure. None of the >>>>> Dependency XSD's get generated in the RAM_Model >>>>> project >>>>> >>>>> 2. TrackingRecordResultWithIterator referenced as >>>>> 'problem:TrackingRecordResultWithIterator' in >>>>> ram_resource_trouble_alarm_resourcealarmretrievalservice_msg.xsd >>>>> is never generated. >>>>> >>>>> 3. Tigerstripe 0.7.0.20120618258. handles >>>>> primitive.string differently and generates type >>>>> 'String' instead of 'java.lang.String' this >>>>> results in type :String instead of xsd:string. I >>>>> did a quick fix given in the following patch adding >>>>> || >>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>> >>>>> to >>>>> || >>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> this means that old and new versions of tigerstipe >>>>> will work >>>>> >>>>> There is a patch below but havent checked this in >>>>> because I was not sure that else you were doing to >>>>> the Soap plugin >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> ### Eclipse Workspace Patch 1.0 >>>>> #P TIP_Soap_Generator >>>>> Index: >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> =================================================================== >>>>> --- >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> (revision 3453) >>>>> +++ >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XmlSchemaHelpers.java >>>>> (working copy) >>>>> @@ -510,8 +510,8 @@ >>>>> */ >>>>> if (refType.isPrimitive() >>>>> || >>>>> refType.getPackage().equalsIgnoreCase("primitive") >>>>> - || >>>>> "java.lang.String".equalsIgnoreCase(refType >>>>> - .getFullyQualifiedName())) { >>>>> + || >>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> + || >>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>> { // tigerstripe 1.7.0 now generates String and >>>>> not java.lang.String >>>>> PluginLog.logDebug("\'" + refTypeFullName >>>>> + "\' is a primitive type in >>>>> current TIP profile."); >>>>> type = >>>>> mapPrimitivesToXsdType(refType.getName(), >>>>> isArray(refType), >>>>> @@ -519,7 +519,7 @@ >>>>> } >>>>> >>>>> /** >>>>> - * Map datatyeps and enumerations >>>>> + * Map datatypes and enumerations >>>>> */ >>>>> // if (refType.isDatatype() || >>>>> refType.isEnum() >>>>> else if (isDatatype(refType) || >>>>> isEnumeration(refType)) { >>>>> Index: >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> =================================================================== >>>>> --- >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> (revision 3453) >>>>> +++ >>>>> src/org/eclipse/tigerstripe/generators/xml/helpers/XsdReferencesMgr.java >>>>> (working copy) >>>>> @@ -170,8 +170,9 @@ >>>>> private void addReferencedPackage(IType type) { >>>>> >>>>> if (type.isPrimitive() >>>>> - || >>>>> "primitive".equalsIgnoreCase(type.getPackage()) || >>>>> - >>>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName())) >>>>> { >>>>> + || >>>>> "primitive".equalsIgnoreCase(type.getPackage()) >>>>> + || >>>>> "java.lang.String".equalsIgnoreCase(type.getFullyQualifiedName()) >>>>> + || >>>>> "String".equalsIgnoreCase(type.getFullyQualifiedName())) >>>>> { // tigerstripe 1.7.0 now generates String and >>>>> not java.lang.String >>>>> //will map objectName to >>>>> EntityIdentifier or ArrayOfEntityIdentifier >>>>> if >>>>> ("objectName".equalsIgnoreCase(type.getName())){ >>>>> PluginLog.logDebug("type \'" + type >>>>> @@ -378,8 +379,8 @@ >>>>> */ >>>>> if (refType.isPrimitive() >>>>> || >>>>> refType.getPackage().equalsIgnoreCase("primitive") >>>>> - || >>>>> "java.lang.String".equalsIgnoreCase(refType >>>>> - .getFullyQualifiedName())) { >>>>> + || >>>>> "java.lang.String".equalsIgnoreCase(refType.getFullyQualifiedName()) >>>>> + || >>>>> "String".equalsIgnoreCase(refType.getFullyQualifiedName())) >>>>> { // tigerstripe 1.7.0 now generates String and >>>>> not java.lang.String >>>>> PluginLog.logDebug("\'" + typeName >>>>> + "\' is a primitive type in >>>>> current TIP profile."); >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 11/06/2012 12:35, Xose Ramon Sousa Vazquez wrote: >>>>> >>>>> Hi all. I think that I have found the error and I >>>>> will try to fix it as soon as possible. There are >>>>> some related issues, one error in the codification >>>>> of a method and a forgetted evaluation of >>>>> filtering in the velocity template and also a case >>>>> related with primitive type filter not supported >>>>> in the build of the closure outside the interfaces. >>>>> >>>>> In the interfaces build the search is performed as >>>>> follows(this works fine as reported Marc): >>>>> >>>>> if >>>>> ("objectName".equalsIgnoreCase(argType.getName())) { >>>>> /* >>>>> * This data type >>>>> 'objectName' defines the protocol >>>>> * neutral unique name of >>>>> an object. This data type will >>>>> * be replaced by the >>>>> generators by an EntityIdentifier >>>>> */ >>>>> String pkg = PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG); >>>>> if >>>>> (!this.map.containsKey(pkg)) { >>>>> // >>>>> // New package - add >>>>> new pkg=prefix mapping >>>>> // assignment >>>>> // >>>>> String prefix = >>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>> pkg, this.map); >>>>> this.map.put(pkg, prefix); >>>>> } >>>>> } else if >>>>> ("filter".equalsIgnoreCase(argType.getName())) { >>>>> /* >>>>> * This data type >>>>> 'filter'. This data type will >>>>> * be replaced by the >>>>> generator to >>>>> */ >>>>> String pkg = PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_FILTER_PKG); >>>>> if >>>>> (!this.map.containsKey(pkg)) { >>>>> // >>>>> // New package - add >>>>> new pkg=prefix mapping >>>>> // assignment >>>>> // >>>>> String prefix = >>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>> pkg, this.map); >>>>> this.map.put(pkg, prefix); >>>>> } >>>>> } else if >>>>> (XmlSchemaHelpers.isUnbounded(argType)) { >>>>> String pkg = PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG); >>>>> if >>>>> (!this.map.containsKey(pkg)) { >>>>> // >>>>> // New package - add >>>>> new pkg=prefix mapping >>>>> // assignment >>>>> // >>>>> String prefix = >>>>> XmlSchemaHelpers.generateXmlPrefix( >>>>> pkg, this.map); >>>>> this.map.put(pkg, prefix); >>>>> } >>>>> } else { >>>>> // XSD default namespace >>>>> is enough >>>>> } >>>>> >>>>> and in the build of the closure we have got (this >>>>> fails as reported Craig): >>>>> >>>>> if ("objectName".equalsIgnoreCase(type.getName())){ >>>>> PluginLog.logDebug("type \'" + type >>>>> + "\' is an array of primitive."); >>>>> addReferencedPackage(PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PKG)); >>>>> }else if >>>>> (XmlSchemaHelpers.isUnbounded(type)){ >>>>> //will map to array of primitive >>>>> addReferencedPackage(PluginConstants >>>>> .getPropVal(PluginConstants.KEY_INTERNAL_MODEL_PRIMITIVES_PKG)); >>>>> } else { >>>>> //normal primtive like xsd:int >>>>> } >>>>> >>>>> so the filtering never is considered. >>>>> >>>>> I will perform clean tests because was very >>>>> difficult to find the real cause of the problem, >>>>> the log file is not very clear in debug scenarios >>>>> ( a lot of similar log text, no log from the >>>>> templates and also cannot put the line number in >>>>> the log file (tigerstripe issue)) and these >>>>> problems have delayed my response. >>>>> If the test go ok I will check out the changes to >>>>> the trunk >>>>> >>>>> https://openoss.svn.sourceforge.net/svnroot/openoss/tip/framework/TIP_Soap_Generator/trunk/TIP_Soap_Generator >>>>> >>>>> Best regards >>>>> >>>>> >>>>> El 01/06/2012 16:58, Craig Gallen escribió: >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> I agree it is defined in internal_filter.xsd but it doesn't seem to be >>>>> >>>>> referenced properly from dep_cbe_perf_spec.xsd in the PM project. WSDL2Java >>>>> >>>>> throws an error and when you open dep_cbe_perf_spec.xsd in eclipse it also >>>>> >>>>> shows an error. >>>>> >>>>> >>>>> >>>>> I think Xose is looking into it >>>>> >>>>> >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: Flauw, Marc [mailto:Mar...@hp...] >>>>> >>>>> Sent: 01 June 2012 10:25 >>>>> >>>>> To: Craig Gallen (opennms); openoss-devel; Xose Ramon Sousa Vazquez; pierre >>>>> >>>>> gauthier >>>>> >>>>> Subject: RE: Problems with PM XSD generation >>>>> >>>>> >>>>> >>>>> Craig, >>>>> >>>>> >>>>> >>>>> There is one same filter in the getReosurceAlarms operation, filter >>>>> >>>>> argument. >>>>> >>>>> The XPathFilter is defined in the internal_filter.xsd >>>>> >>>>> >>>>> >>>>> Best regards >>>>> >>>>> >>>>> >>>>> Marc >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig >>>>> >>>>> Gallen (opennms) >>>>> >>>>> Sent: Thursday, May 31, 2012 11:58 PM >>>>> >>>>> To: openoss-devel; Flauw, Marc; Xose Ramon Sousa Vazquez; pierre gauthier >>>>> >>>>> Subject: Problems with PM XSD generation >>>>> >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> I have been testing the TIP_PM_Col project model and have found that the >>>>> >>>>> dep_cbe_perf_spec.xsd (attached) file is generated with errors >>>>> >>>>> >>>>> >>>>> in line 62 we have >>>>> >>>>> <xsd:element name="objectInstanceFilter" type="filter:XPathQueryFilter" >>>>> >>>>> minOccurs="0" maxOccurs="1"> >>>>> >>>>> >>>>> >>>>> filter:XPathQueryFilter is not defined and if you open the file in eclipse >>>>> >>>>> it reports this error as: >>>>> >>>>> >>>>> >>>>> 's4s-att-invalid-value: Invalid attribute value for 'type' in element >>>>> >>>>> 'element'. Recorded reason: >>>>> >>>>> UndeclaredPrefix: Cannot resolve 'filter:XPathQueryFilter' as a QName: >>>>> >>>>> the prefix 'filter' is not >>>>> >>>>> declared'. >>>>> >>>>> >>>>> >>>>> Is this a known problem or a new bug? >>>>> >>>>> >>>>> >>>>> Craig >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>>> Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>>> Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS >>>>> Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, >>>>> Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>>> -- >>>>> >>>>> *Xose Ramon Sousa Vazquez*| Director OSS Technologies, Director I+D >>>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>>> www.optaresolutions.com >>>>> <http://www.optaresolutions.com> >>>>> Optare Solutions <http://optarecoolvendor.com> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >>>> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >>>> www.optaresolutions.com >>>> <http://www.optaresolutions.com> >>>> Optare Solutions >>>> <http://optarecoolvendor.com><http://optarecoolvendor.com> >>>> >>> >>> >> >> >> -- >> >> *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D >> T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 >> www.optaresolutions.com >> <http://www.optaresolutions.com> >> Optare Solutions >> <http://optarecoolvendor.com><http://optarecoolvendor.com> >> > > -- *Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029 www.optaresolutions.com <http://www.optaresolutions.com> Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com> |
Thanks for helping keep SourceForge clean.
X