Bugzilla – Full Text Bug Listing
| Summary: | [LML] Add support for customization of system monitoring view | ||
|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Claudia Knobloch <cla.knobloch> |
| Component: | RM | Assignee: | Carsten Karbach <c.karbach> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | beth, bwatt, c.karbach, g.watson, W.Frings |
| Version: | 5.0.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Claudia Knobloch
Created attachment 204930 [details]
Default LML request for compute resources with torque
Comment on attachment 204930 [details] Default LML request for compute resources with torque <?xml version="1.0" encoding="UTF-8"?> <!--- Copyright (c) 2011 Forschungszentrum Juelich GmbH. All rights reserved. This program and the accompanying materials are made available under the terms of the Eclipse Public License v1.0 which accompanies this distribution, and is available at http://www.eclipse.org/legal/epl-v10.html Contributors: Wolfgang Frings (Forschungszentrum Juelich GmbH) --> <lml:lgui xmlns:lml="http://www.llview.de" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.llview.de lgui.xsd " version="1.0"> <objects> <object color="#FFFFFF" id="empty" name="Empty job" type="job"/> </objects> <nodedisplay title="default" id="__dummy_nd__1__"> <scheme><el1 min="0" tagname="__empty__"></el1></scheme> <data><el1 min="0" oid="empty"></el1></data> </nodedisplay> <nodedisplaylayout id="nodedisplay" gid="__dummy_nd__1__"> <el0 rows="0" cols="0"> </el0> </nodedisplaylayout> <tablelayout id="tl_Run" gid="joblistrun" active="true"> <column cid="1" pos="0" width="1" active="true" key="step" /> <column cid="2" pos="1" width="1" active="true" key="owner" /> <column cid="3" pos="2" width="1" active="true" key="queue" /> <column cid="4" pos="3" width="1" active="true" key="wall" /> <column cid="5" pos="4" width="1" active="true" key="queuedate" /> <column cid="6" pos="5" width="1" active="true" key="dispatchdate" /> <column cid="7" pos="6" width="1" active="true" key="totalcores" /> <column cid="8" pos="7" width="1" active="true" key="state" /> </tablelayout> <table title="Running" id="joblistrun" contenttype="jobs" description="This is the table showing all running jobs"> <column id="1" name="step"/> <column id="2" name="owner"> <pattern> <include regexp=".*"/> </pattern></column> <column id="3" name="queue"/> <column id="4" name="wall"/> <column id="5" name="queuedate"/> <column id="6" name="dispatchdate"/> <column id="7" name="totalcores"/> <column id="8" name="state" type="mandatory"> <pattern> <include regexp="Running"/> </pattern> </column> </table> <tablelayout id="tl_WAIT" gid="joblistwait" active="false"> <column cid="1" pos="0" width="1" active="true" key="step" /> <column cid="2" pos="1" width="1" active="true" key="owner" /> <column cid="3" pos="2" width="1" active="true" key="queue" /> <column cid="4" pos="3" width="1" active="true" key="wall" /> <column cid="5" pos="4" width="1" active="true" key="queuedate" /> <column cid="6" pos="5" width="1" active="true" key="dispatchdate" /> <column cid="7" pos="6" width="1" active="true" key="totalcores" /> <column cid="8" pos="7" width="1" active="true" key="state" /> </tablelayout> <table title="Waiting" id="joblistwait" contenttype="jobs" description="This is the table showing all waiting jobs"> <column id="1" name="step"/> <column id="2" name="owner"> <pattern> <include regexp=".*"/> </pattern></column> <column id="3" name="queue"/> <column id="4" name="wall"/> <column id="5" name="queuedate"/> <column id="6" name="dispatchdate"/> <column id="7" name="totalcores"/> <column id="8" name="state" type="mandatory"> <pattern> <include regexp="Idle"/> </pattern> </column> </table> <table title="Nodes" id="nodelist" contenttype="nodes" description="This is the table contain all nodes of the system"> <column id="1" name="id" sort="alpha" type="mandatory"></column> <column id="2" name="ncores"></column> <column id="3" name="physmem" sort="alpha"/> <column id="4" name="state" sort="alpha"/> </table> <tablelayout id="nodes" gid="nodelist" active="false"> <column cid="1" pos="0" width="1" active="true" key="id" /> <column cid="2" pos="1" width="1" active="true" key="ncores" /> <column cid="3" pos="2" width="1" active="true" key="physmem" /> <column cid="4" pos="3" width="1" active="true" key="state" /> </tablelayout> </lml:lgui> The attachment is the default request, which is sent to lml_da. All tags, which can be found in this example, have to be stored in the LML request configuration. A possible solution for saving this configuration within PTP is to integrate the request into the resource manager configuration to have only one configuration file for a resource. (In reply to comment #3) > The attachment is the default request, which is sent to lml_da. All tags, which > can be found in this example, have to be stored in the LML request > configuration. A possible solution for saving this configuration within PTP is > to integrate the request into the resource manager configuration to have only > one configuration file for a resource. Is there only ever likely to be one type of request per resource manager? Or might there be a need for multiple request types? I think this could be fairly easily added to the monitor-data section of the RM configuration file. In order to add an LML layout into the target system configuration, we could adjust the resource_manager_type.xsd by replacing the current monitor-type with the following: <xs:complexType name="monitor-type"> <xs:sequence> <xs:element name="driver" minOccurs="0" maxOccurs="unbounded" type="rm:monitor-driver-type" /> <xs:element name="workflow" minOccurs="0" maxOccurs="unbounded" type="rm:workflow-type" /> <xs:element ref="Q1:lgui" minOccurs="0" maxOccurs="*"></xs:element> </xs:sequence> <xs:attribute name="schedulerType" type="xs:string"/> <xs:attribute name="refreshFrequencyInSeconds" type="xs:int" default="60"/> </xs:complexType> This would also require to import the LML XSD file: <xs:import schemaLocation="http://eclipse.org/ptp/schemas/lgui.xsd" namespace="http://www.llview.de"/> This approach would be the easiest solution for integrating an LML layout file into the target system configuration. However, it would also cause all JAXB classes needed for the LML XSD to be added to the org.eclipse.ptp.rm.jaxb.core.data package. The problem with this is that it includes the whole LML schema in the target configuration schema. I thought we were going to try to separate out only the request type so that only this part of the schema would be added? You are right. I just didn't remember, why we decided to separate the layout from the data part. I will have a look on how to separate these parts in LML. The separation would also demonstrate the two use cases of LML as request and response data format. Created attachment 225457 [details]
This patch is a first approach for splitting the request part of LML from its data part.
This patch implements splitting the LML request and data part into independent XSDs.
Changes for LML
It adds the special root element <layout>...</layout> for LML request files. Thus, LML requests and LML responses can easily be distinguished. The layout element could become part of the monitoring data in the resource manager configuration files.
All data, which is needed by lml_da within an LML request, is now given by an LML layout file. Therefore, the filtering information had to be shifted from the table element to the tablelayout. Moreover, the nodedisplaylayout contains an <schemehint> element, which describes the supercomputer's hierarchy. The schemehint is used as the actual scheme in the nodedisplay generated by lml_da.
The target namespace is now renamed into org.eclipse.ptp.lml, which fits better to the target namespace used for the RM schema.
Changes for monitoring client and LML_da
Along with adapting the LML format the monitoring client as well as lml_da have to make use of the new format. These adaptions are also included in this patch. The monitoring client (org.eclipse.ptp.rm.lml.core) now sends a pure layout file containing only layout elements to lml_da. The server lml_da needs to interpret the new format accordingly.
Testing
The patch is based on ptp_6_0 and I created it via command line. Note, that you might have to re-run the build.xml file of the org.eclipse.ptp.lml.da.server plug-in and to delete the ".eclipsesettings" folder on your target system in order to update the lml_da scripts.
I have tested it on all remote systems I have access on. I would appreciate others testing it on their systems in order to avoid breaking anything. Since this is a rather big adaption for the monitoring system, I would like to test it first and commit it as soon as I have got some feedback. Or should I commit this patch in order to simplify testing, but with having the risk that monitoring might not work on all systems?
Can you please generate a patch against master rather than ptp_6_0? Since SR2 is now done, this will need to go into Kepler. There have been a number of changes in master, including a namespace change that you'll need to pick up. Also, I noticed some debugging in the code. Please make sure it's taken out. Thanks! Created attachment 227464 [details]
This is the corresponding patch based on the master branch.
This patch is based on the master branch. I have created it via Eclipse. It separates the LML layout elements from the data elements. It also updates the JAXB classes in the plug-in org.eclipse.ptp.rm.lml.core. The JAXB classes in the rm.jaxb.* plug-ins are not changed, since I do not know exactly how you would like to include the layout element of LML into the control monitor data.
I suggest to add an optional element of type lml:layout_root into the monitor-data tag. The type lml:layout_root is defined in the layout.xsd file of the lml.core plug-in.
This patch looks ok to me if you' like to commit it. The patch in attachment 227464 [details] has been committed to master.
Changed title of bug. I'm now seeing this exception: org.xml.sax.SAXParseException: cvc-elt.1: Cannot find the declaration of element 'lml:lgui'. at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.createSAXParseException(ErrorHandlerWrapper.java:195) at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(ErrorHandlerWrapper.java:131) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:384) at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(XMLErrorReporter.java:318) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.handleStartElement(XMLSchemaValidator.java:1922) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaValidator.startElement(XMLSchemaValidator.java:711) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:400) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl$NSContentDriver.scanRootElementHook(XMLNSDocumentScannerImpl.java:626) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:3104) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:921) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:647) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:511) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737) at com.sun.org.apache.xerces.internal.jaxp.validation.StreamValidatorHelper.validate(StreamValidatorHelper.java:147) at com.sun.org.apache.xerces.internal.jaxp.validation.ValidatorImpl.validate(ValidatorImpl.java:111) at javax.xml.validation.Validator.validate(Validator.java:127) at org.eclipse.ptp.rm.lml.core.util.JAXBUtil.validate(JAXBUtil.java:317) at org.eclipse.ptp.rm.lml.core.util.JAXBUtil.unmarshal(JAXBUtil.java:769) at org.eclipse.ptp.rm.lml.internal.core.model.LguiItem.update(LguiItem.java:591) at org.eclipse.ptp.rm.lml.core.LMLManager.update(LMLManager.java:249) at org.eclipse.ptp.rm.lml.monitor.core.MonitorControl$MonitorJob.run(MonitorControl.java:102) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53) Sorry, I forgot you needed to reload the DA driver. It's ok now. In terms of including the LML schema into the resource manager schema, I have found the following: You can include an external Schema with the xs:import tag, which could look like this: <xs:schema targetNamespace="org.eclipse.ptp" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:rm="org.eclipse.ptp" elementFormDefault="qualified" xmlns:Q1="http://www.llview.de"> <xs:import schemaLocation="http://eclipse.org/ptp/schemas/lgui.xsd" namespace="http://www.llview.de"/> This is an example for the old namespaces. Moreover, you can tell the jaxb compiler xjc which package names to use when compiling the classes. Therefore, create a jaxb bindings configuration, in which you specify the package name for each namespace. Here is an example for the two old namespaces: <?xml version="1.0" encoding="UTF-8"?> <jxb:bindings version="1.0" xmlns:jxb="http://java.sun.com/xml/ns/jaxb" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <jxb:bindings xmlns="http://www.llview.de"> <jxb:bindings schemaLocation="../../org.eclipse.ptp.rm.lml.core/schema/.xsd"> <jxb:schemaBindings> <jxb:package name="lml"/> </jxb:schemaBindings> </jxb:bindings> </jxb:bindings> <jxb:bindings xmlns="org.eclipse.ptp"> <jxb:bindings schemaLocation="resource_manager_type.xsd"> <jxb:schemaBindings> <jxb:package name="tsc"/> </jxb:schemaBindings> </jxb:bindings> </jxb:bindings> </jxb:bindings> When compiling the jaxb classes, you have to pass this bindings file to the xjc compiler. E.g. "xjc -b jaxbBindings.xml resource_manager_type.xsd", where jaxbBindings.xml contains the above example. However, this only works for schemas of different namespaces, so that we would need to rename for instance the LML namespace again. If you compile the jaxb classes with the corresponding package, you could make the resource_manager_type classes include the jaxb classes from the lml.core plug-in. But, I do not know if the marshalling/unmarshalling will work in this use case. Alternatively, you would have the LML layout classes twice. This is a good article also: http://www.xfront.com/ZeroOneOrManyNamespaces.html Created attachment 228647 [details]
This patch avoids overriding user defined scheme elements in nodedisplays.
The adapted LML2LML module currently overrides user defined scheme elements of nodedisplays for all target systems except PBS and Cluster. This is fixed by the attached patch. Now, LML2LML checks, whether there is a user defined scheme given. If that is true, this scheme is used for the nodedisplay generation. Otherwise, the default scheme for the particular target system is created and used.
This has been committed to master.
Carsten, I think a first step towards this is that the RM and LML schemas need to use different namespaces (currently they both use "http://eclipse.org/ptp/schemas") otherwise we're going to have an issue with element/type name clashes. I would suggest using "http://eclipse.org/ptp/rm" for the RM namespace and "http://eclipse.org/ptp/lml" for the LML namespace. Once we do this, we can the import the layout XSD into the RM XSD as follows: <xs:import namespace="http://eclipse.org/ptp/lml" schemaLocation="http://eclipse.org/ptp/schemas/layout.xsd"/> We can then add a layout element to the monitor-type as follows: <xs:complexType name="monitor-type"> <xs:sequence> <xs:element name="driver" minOccurs="0" maxOccurs="unbounded" type="rm:monitor-driver-type"/> <xs:element name="workflow" minOccurs="0" maxOccurs="unbounded" type="rm:workflow-type"/> <xs:element name="layout" minOccurs="0" maxOccurs="1" type="lml:layout_root"/> </xs:sequence> <xs:attribute name="schedulerType" type="xs:string"/> <xs:attribute name="refreshFrequencyInSeconds" type="xs:int" default="60"/> </xs:complexType> Does this sound ok? If so, I'll modify the namespaces first to make sure that everything is still working. This sounds good. Note, that the namespace appears a couple of times in lml.core and lml.da. Here especially the files within the samples directory need to have correct namespaces. Namespace has been changed. Is there any reason why LML_file_obj::write_lml is not used to create the reply, rather than each rms formatting it individually? This would greatly simplify changes like this in the future. The only reason I can see is that currently the rms scripts are entirely independent. You do not need any additional library scripts. However, this causes a lot of redundant code. A similar problem is discussed in bug 393148. If you need to change anything in the "redundant" code such as XML escaping or the LML namespace, you have to repeat the adaption for each rms. I think we should refactor these scripts and extract common code. This includes using LML_file_obj::write_lml for LML generation. We should check the Wolfgang is ok with this also. The "[360435] Update RM schema location and namespace." change has affected anyone using the RM and ETFw schemas to require them to change their XML files. For example from <etfwTool xmlns="http://org.eclipse.ptp/etfw" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:rm="http://eclipse.org/ptp/schemas" ... to <etfwTool xmlns="http://eclipse.org/ptp/etfw" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:rm="http://eclipse.org/ptp/rm" ... Since this is an upward compatibility impact, we should probably announce this publicly as part of the release notes, but that outside of my scope of knowledge as to if and/or how this is done. I just did a search for "http://org.eclipse.ptp/rm" and I'm still find occurrences in org.eclipse.ptp.rm.jaxb.doc.isv/html/tokenizer-examples.xml and org.eclipse.ptp.rm.jaxb.tests/data/*.xml. Should these be updated too? (In reply to comment #23) > We should check the Wolfgang is ok with this also. I have discussed this with Wolfgang. In general, he agrees with refactoring the server scripts in org.eclipse.ptp.rm.lml.da/rms. But the scripts should be independent at least within the rms folder. They should not call external scripts from org.eclipse.ptp.rm.lml.da/lib. Rather a new lib directory should be placed into the rms folder. This would minimize dependencies and would keep the server scripts simple. (In reply to comment #21) > Namespace has been changed. Is there any reason why LML_file_obj::write_lml > is not used to create the reply, rather than each rms formatting it > individually? This would greatly simplify changes like this in the future. Now that the namespaces are separated, could we add the layout element into the RM XSD as you described in Comment 19 ? Then we would only need to send this LML layout as default layout, when the system monitoring connects to a new system for the first time. Created attachment 233711 [details] First try on including the LML layout into the RMS configuration This patch is created against the ptp_7_0 branch. It adds the layout element into the resource_manager_type.xsd. As a result new jaxb classes had to be generated via xjc. In order to avoid name conflicts the org.eclipse.ptp.rm.jaxb.core/schema/namespace_bindings.xml is used when compiling the jaxb classes. This ensures, that all LML classes are placed in a separate package. An example TSC with an integrated LML layout is given by org.eclipse.ptp.rm.jaxb.contrib/data/de.fz-juelich.judge.torque.batch.xml. Finally, the lml.monitor.core had to be adjusted: the LML layout from the TSC has to be propagated to LML_DA. To test this feature after applying the patch, you can do the following: 1) Adapt the particular TSC in the org.eclipse.ptp.rm.jaxb.contrib plug-in or as described in http://wiki.eclipse.org/PTP/FAQ#Q:_How_do_I_customize_an_existing_Target_System_Configuration.3F by adding an LML layout. In order to get a layout template for your target system, you can do the following: - connect with the monitoring perspective to your remote machine, so that the .eclipsesettings directory is created - create within this directory the .LML_da_options file with the content "keeptmp=1" - refresh your monitoring connection, which will create a tmp-directory in the .eclipsesettings directory - use the layout.xml file in this directory as template for the layout, which you want to configure in the TSC The exact allowed format for the layout config is documented here: http://llview.zam.kfa-juelich.de/LML/OnlineDocumentation/lmldoc/layout.xsd.html#type_layout_root 2) Create a new monitoring connection with the adapted TSC 3) Connect with this connection to the remote machine This should send the configured layout to LML_DA. If you want to adapt your TSC again, you need to re-create the monitoring connection again, because the default layout is only send on the first connect. There are still a few problems with this patch: - the updated resource_manager_type.xsd needs to be published again under http://eclipse.org/ptp/schemas/v1.2/ - All references to the old URL have to be changed to the new one - In order to test the new schema for now, I have pointed the schemaLocation for the lml schema to the webserver http://llview.zam.kfa-juelich.de, which has to be changed as soon as the new schema versions are uploaded - Since the jaxb.core plug-in is exported API, the version number of this plug-in needs to be increased. I am not sure, if I did that correctly in this patch (simply increased to 1.2.0) - It is probably not allowed to make API changes in the 7.0 branch, so that this feature can only be included in the master branch @Greg: I am not sure, if all of the changes in the above patch are reasonable. Especially, the version numbering due to the API change. Could you have a look on the changes in the jaxb.core plug-in? Moreover, if we want to use the schema changes, the updated schema files need to be published at the webserver. Could we place a new version of the LML schema files and RM schema files on the web? After pointing the schema URLs to the updated schema location, would the patch be ok to be committed? Should it be committed only to the master branch? I'll try to take a look at this today. We can put this into ptp_7_0 but would need to do a 7.1 release. This is not out of the question, but does require a release review so would need to be scheduled a few weeks in advance. I tried applying the patch to the master branch, but it's saying the patch is already applied. Can you regenerate it against the latest master branch? Created attachment 233776 [details]
Patch 233711 regenerated against the current master branch.
This patch is almost identical to patch 233711. It is generated against the current master branch.
Patch 233711 applies, thanks. I have the following comments: 1. I'm getting build errors in LayoutRoot.java and PatternType.java. It looks like you've compiled them using Java 1.7 which uses a different version of JAXB. You'll need to recompile with Java 1.6 since we're not requiring 1.7 at this time. 2. You should remove the API problem filters. 3. The schema location should be "http://eclipse.org/ptp/schemas/layout.xsd" not "http://llview.zam.kfa-juelich.de/LML/OnlineDocumentation/XSD/layout.xsd" 4. Unexternalized strings have been introduced. These should be refactored as static strings and externalized. I think this can be applied to ptp_7_0 provided the org.eclipse.ptp.rm.jaxb.core.data.lml package is not exported. If you want to fix these issues and resubmit a patch for ptp_7_0, I'll take another look. Thanks! (In reply to comment #33) > Patch 233711 applies, thanks. I have the following comments: > > 1. I'm getting build errors in LayoutRoot.java and PatternType.java. It > looks like you've compiled them using Java 1.7 which uses a different > version of JAXB. You'll need to recompile with Java 1.6 since we're not > requiring 1.7 at this time. The current version of the jaxb.core.data classes (in master and ptp_7_0) is compiled with Java 1.7. The header mentions a version of v2.2.4-2 used for the class compilation. Thus, I also used Java 1.7, because using 1.6 introduced changes like: @XmlAttribute(name = "redirectStderr") -> @XmlAttribute > > 2. You should remove the API problem filters. Should all API problem filters be removed? There were filters for the jaxb.core.data package before the patch. > > 3. The schema location should be "http://eclipse.org/ptp/schemas/layout.xsd" > not "http://llview.zam.kfa-juelich.de/LML/OnlineDocumentation/XSD/layout.xsd" > I agree. But the version at http://eclipse.org/ptp/schemas/layout.xsd is old. It does not include the namespace changes and the split of LML into data and layout section. It looks like http://eclipse.org/ptp/schemas/v1.1/layout.xsd now contains the current LML version. In addition, the patch also updates the resource_manager_type.xsd, which also needs to be updated on the webserver as soon as the patch is actually committed. Due to the old version on the webserver my example TSC de.fz-juelich.judge.torque.batch.xml including an LML layout has to reference the rm XSD with xsi:schemaLocation="http://eclipse.org/ptp/rm ../../org.eclipse.ptp.rm.jaxb.core/schema/resource_manager_type.xsd", because the patch itself changes the rm XSD. As soon as the new rm XSD is on the web, this URL has to be adjusted to http://eclipse.org/ptp/rm http://eclipse.org/ptp/schemas/v1.1/rm.xsd again. > 4. Unexternalized strings have been introduced. These should be refactored > as static strings and externalized. Do you also mean those introduced by the JAXB classes? These unexternalized strings were present before my patch. I do not know if adjusting the JAXB classes influences the marshalling/unmarshalling process. > > I think this can be applied to ptp_7_0 provided the > org.eclipse.ptp.rm.jaxb.core.data.lml package is not exported. If you want > to fix these issues and resubmit a patch for ptp_7_0, I'll take another look. > > Thanks! When I do not export org.eclipse.ptp.rm.jaxb.core.data.lml, the MonitorType class will be using a non-API return type LayoutRoot. Is that acceptable? Created attachment 233819 [details]
Include LML layout into RMS configuration
The JAXB classes are now generated with Java 1.6. The API problem filters are removed for the jaxb.core.lml package. The @since tags are corrected, where @since tags with version 1.1 appeared. The non-externalized strings are externalized. The schema location for the LML layout schema is corrected.
(In reply to comment #34) > (In reply to comment #33) > > Patch 233711 applies, thanks. I have the following comments: > > > > 1. I'm getting build errors in LayoutRoot.java and PatternType.java. It > > looks like you've compiled them using Java 1.7 which uses a different > > version of JAXB. You'll need to recompile with Java 1.6 since we're not > > requiring 1.7 at this time. > > The current version of the jaxb.core.data classes (in master and ptp_7_0) is > compiled with Java 1.7. The header mentions a version of v2.2.4-2 used for the > class compilation. Thus, I also used Java 1.7, because using 1.6 introduced > changes like: > @XmlAttribute(name = "redirectStderr") -> @XmlAttribute Strange, because the version you generated had "required = false" which is 1.7 feature. > > > > > 2. You should remove the API problem filters. > > Should all API problem filters be removed? There were filters for the > jaxb.core.data package before the patch. Since both packages will be exported, filters will be required on both. See below. > > > > > 3. The schema location should be "http://eclipse.org/ptp/schemas/layout.xsd" > > not "http://llview.zam.kfa-juelich.de/LML/OnlineDocumentation/XSD/layout.xsd" > > > > I agree. But the version at http://eclipse.org/ptp/schemas/layout.xsd is old. It > does not include the namespace changes and the split of LML into data and layout > section. It looks like http://eclipse.org/ptp/schemas/v1.1/layout.xsd now > contains the current LML version. Yes, this should be the latest version. > In addition, the patch also updates the resource_manager_type.xsd, which also > needs to be updated on the webserver as soon as the patch is actually committed. > Due to the old version on the webserver my example TSC > de.fz-juelich.judge.torque.batch.xml including an LML layout has to reference > the rm XSD with xsi:schemaLocation="http://eclipse.org/ptp/rm > ../../org.eclipse.ptp.rm.jaxb.core/schema/resource_manager_type.xsd", because > the patch itself changes the rm XSD. As soon as the new rm XSD is on the web, > this URL has to be adjusted to http://eclipse.org/ptp/rm > http://eclipse.org/ptp/schemas/v1.1/rm.xsd again. > > > 4. Unexternalized strings have been introduced. These should be refactored > > as static strings and externalized. > > Do you also mean those introduced by the JAXB classes? These unexternalized > strings were present before my patch. I do not know if adjusting the JAXB > classes influences the marshalling/unmarshalling process. No, I mean the strings in MonitorControlManager.java. These should be declared as static final in the class and //NON-NLS added. They should not be added to the messages, since they do not need translation. > > > > > I think this can be applied to ptp_7_0 provided the > > org.eclipse.ptp.rm.jaxb.core.data.lml package is not exported. If you want > > to fix these issues and resubmit a patch for ptp_7_0, I'll take another look. > > > > Thanks! > > When I do not export org.eclipse.ptp.rm.jaxb.core.data.lml, the MonitorType > class will be using a non-API return type LayoutRoot. Is that acceptable? No. I overlooked this. These changes will require a 7.1 release, so I think we should put it in the master branch for now. In which case we may as well as export the core.data.lml package as well. (In reply to comment #35) > Created attachment 233819 [details] > Include LML layout into RMS configuration > > The JAXB classes are now generated with Java 1.6. The API problem filters are > removed for the jaxb.core.lml package. The @since tags are corrected, where > @since tags with version 1.1 appeared. The non-externalized strings are > externalized. The schema location for the LML layout schema is corrected. I'm ok with this going into the master branch with the following changes: 1. Export both the jaxb.core.data and jaxb.core.data.lml but add problem filters for @since. 2. Remove the strings from Messages.java and messages.properties. Declare these as static final in MonitorControlManager.java and add //NON-NLS to the declarations. The new schemas will need to be v1.2 and put up on the web server. You'll need to reference the v1.2 versions, so I'll upload the new versions as soon as you've committed. Thanks! I have adjusted patch 233819 according to comment 37 and committed it to the master branch. I incremented the rm schema version to 1.2 and uploaded to eclipse.org/schemas/v1.2/rm.xsd. Together with the updated schema version the API filters for the org.eclipse.ptp.rm.jaxb.core.data package were removed. I am now getting API problems like "Missing @since tag on org.eclipse.ptp.rm.jaxb.core.data.AddType". Did you remove these filters intentionally? (In reply to comment #40) > Together with the updated schema version the API filters for the > org.eclipse.ptp.rm.jaxb.core.data package were removed. I am now getting API > problems like "Missing @since tag on > org.eclipse.ptp.rm.jaxb.core.data.AddType". Did you remove these filters > intentionally? Have you updated your API baseline to 7.0? I removed the filters as I was getting warnings that they were unused. No, I forgot the API baseline for my master workspace. That solved my problem. Thanks! Customization of system monitoring perspective is now included in the master branch. |