如果找到了对您有用的资料,烦请点击右手边的Google广告支持我继续共享知识,谢谢! http://dengpeng.spaces.live.com/

2008年10月25日星期六

XMLBeans and SensorML conflict

Digested from: http://forums.sun.com/thread.jspa?threadID=5332907

Hi all,
i have run out of all ideas and i am in a desperate need of help here, our project is stuck in the middle because of this.
I am using xmlbeans to bind xml to java objects. We are using OM, SWE and GML (opengis.net) schema specifications for our xmls. Xmlbeans has no problem creating schema if i am not importing any of the above schemas but when i try to i get the following error

addNewLocation() in net.opengis.sensorML.x101.AbstractDerivableComponentType clashes with addNewLocation() in net.opengis.gml.AbstractFeatureType; attempting to use incompatible return type
found: net.opengis.sensorML.x101.LocationDocument.Location
required: net.opengis.gml.LocationPropertyType

I've researched this for a while and found out that the problem is within SensorML schema and here is a apparent fix for this: [ https://52north.org/twiki/bin/view/Sensornet/SensorML| https://52north.org/twiki/bin/view/Sensornet/SensorML]
Now I am assuming that I am to download (using xmlbeans' sdownload tool) the system.xsd from SensorML folder (schemas.opengis.net) and make that change and since sdownload will create a catalog file, i use that catalog file when compiling the schema and xmlbean will look at the system.xsd on my local machine and go to the net for everything else.
The above is obviously not working since I don't think it ever looks at the system.xsd on my local machine but go to the net for it and obviously stumbles upon the problem.
Does anybody have any idea what i am talking about and how i can fix this?
I will greatly appreciate any insights into this problem. Our project is stuck at this and we can't move forward until this is resolved. thanks

so fixed my own problem :D, oh what a relief.
here is what i did in case some other poor soul encounters this issue.
- I downloaded SCHEMAS_OPENGIS_NET.zip from http://schemas.opengis.net/
- made the changes to the system.xsd file that were suggested here: https://52north.org/twiki/bin/view/Sensornet/SensorML
- my xsd file imported name space like the following

here is what i did in case some other poor soul encounters this issue.
- I downloaded SCHEMAS_OPENGIS_NET.zip from http://schemas.opengis.net/
- made the changes to the system.xsd file that were suggested here: https://52north.org/twiki/bin/view/Sensornet/SensorML
- my xsd file imported name space like the following

<import namespace="http://www.opengis.net/gml" schemaLocation="http://schemas.opengis.net/gml/3.1.1/base/gml.xsd"/>
<import namespace="http://www.opengis.net/swe/1.0.1" schemaLocation="http://schemas.opengis.net/sweCommon/1.0.1/swe.xsd"/>
<include schemaLocation="http://schemas.opengis.net/om/1.0.0/om.xsd"/>


I replaced the url to the name of the above folder. in my case it was SCHEMAS_OPENGIS_NET so now i've



<import namespace="http://www.opengis.net/gml" schemaLocation="SCHEMAS_OPENGIS_NET/gml/3.1.1/base/gml.xsd"/>
<import namespace="http://www.opengis.net/swe/1.0.1" schemaLocation="SCHEMAS_OPENGIS_NET/sweCommon/1.0.1/swe.xsd"/>
<include schemaLocation="SCHEMAS_OPENGIS_NET/om/1.0.0/om.xsd"/>


and that it, compile away :)

reply to this thread if u need help with this issue, i'll try to help if i can :)






Here below is text from https://52north.org/twiki/bin/view/Sensornet/SensorML



Sensor Model Language (SensorML)


SensorML defines concepts and XML encodings for descriptions of sensors, processes and systems. SensorML is used in several OGC SWE web services (e.g. SOS, SPS, SAS).

Compiling SensorML with XmlBeans


If you want to compile the sensorML.xsd schema into Java classes with XmlBeans, you have to do a small change in the schema. Open the system.xsd file and navigate to the definition of sml:AbstractDerivableComponentType. This type is an extension of sml:AbstractProcessType, which is an extension of gml:Feature. That is, why every sml:AbstractDerivableComponent has a location element with type gml:location. The sml:AbstractDerivableComponentType also contains a second location element, which is of type sml:location Having two location elements defined in the sml:AbstractDerivableComponentType leads to compiler errors when compiling the XmlBeans created Java classes.

Solution: The sml:location restricts gml:location to gml:Point and gml:_CurveType. The easiest way to get around with that, is to change the type of the location defined in the sml:AbstractDerivableComponentType at line 24 from sml:location to "gml:location". Although this keeps back the restriction to gml:Point and gml:_CurveType, you can use these types and the schema could be compiled with XmlBeans.



Please write, if you know a better solution!



Validating SensorML with Altova XmlSpy



For those developers, who are using XmlSpy 2005: If you comment out the xs:element name="parameter" type="swe:DataComponentPropertyType" maxOccurs="unbounded" element in line 298, the validation of schema system.xsd should work! -- ChristophStasch - 19 Jun 2007



To validate all SensorML schema with XmlBeans? 2005 rel 3, you also have to outcomment the parameters element in the TransducerType. This is quick and dirty and I will try to see, whether there are better workarounds for this issue. Nevertheless the whole schema do validate for now... -- ChristophStasch - 23 Jun 2007






My comment:



I can successfully compile SensorML using XMLBeans by following the solution from https://52north.org/twiki/bin/view/Sensornet/SensorML. I am not sure why I need to modify the schema location according to http://forums.sun.com/thread.jspa?threadID=5332907. If you have any idea, please let me know. Thanks!

2008年10月21日星期二

SunSPOT Application Template Updated

It seems some API has been changed, but the template file has not reflect these changes yet. Here is the latest template file:

/*
* StartApplication.java
*
* Created on Oct 21, 2008 9:42:46 PM;
*/


package org.sunspotworld;

import com.sun.spot.peripheral.Spot;
import com.sun.spot.sensorboard.EDemoBoard;
import com.sun.spot.sensorboard.peripheral.ISwitch;
import com.sun.spot.sensorboard.peripheral.ITriColorLED;
import com.sun.spot.util.*;

import javax.microedition.midlet.MIDlet;
import javax.microedition.midlet.MIDletStateChangeException;

/**
* The startApp method of this class is called by the VM to start the
* application.
*
* The manifest specifies this class as MIDlet-1, which means it will
* be selected for execution.
*/

public class StartApplication extends MIDlet {

private ITriColorLED [] leds = EDemoBoard.getInstance().getLEDs();

protected void startApp() throws MIDletStateChangeException {
System.out.println("Hello, world");
new BootloaderListener().start(); // monitor the USB (if connected) and recognize commands from host

// long ourAddr = RadioFactory.getRadioPolicyManager().getIEEEAddress();
long ourAddr = Spot.getInstance().getRadioPolicyManager().getIEEEAddress();

System.out.println("Our radio address = " + IEEEAddress.toDottedHex(ourAddr));

ISwitch sw1 = EDemoBoard.getInstance().getSwitches()[EDemoBoard.SW1];
leds[0].setRGB(100,0,0); // set color to moderate red
while (sw1.isOpen()) { // done when switch is pressed
leds[0].setOn(); // Blink LED
Utils.sleep(250); // wait 1/4 seconds
leds[0].setOff();
Utils.sleep(1000); // wait 1 second
}
notifyDestroyed(); // cause the MIDlet to exit
}

protected void pauseApp() {
// This is not currently called by the Squawk VM
}

/**
* Called if the MIDlet is terminated by the system.
* I.e. if startApp throws any exception other than MIDletStateChangeException,
* if the isolate running the MIDlet is killed with Isolate.exit(), or
* if VM.stopVM() is called.
*
* It is not called if MIDlet.notifyDestroyed() was called.
*
* @param unconditional If true when this method is called, the MIDlet must
* cleanup and release all resources. If false the MIDlet may throw
* MIDletStateChangeException to indicate it does not want to be destroyed
* at this time.
*/

protected void destroyApp(boolean unconditional) throws MIDletStateChangeException {
for (int i = 0; i < 8; i++) {
leds[i].setOff();
}
}
}


Please note the 2 lines in bold. This bug only happens when you are using SunSPOTApplicationTemplate 1.8 with Purple SDK, in new Blue SDK, it is not a problem. This problem is because the API change.