如果找到了对您有用的资料,烦请点击右手边的Google广告支持我继续共享知识,谢谢! http://dengpeng.spaces.live.com/
2008年10月30日星期四
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月23日星期四
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.