Hi all,
For those interested in the WPS development, here is a design issue:
Right now I am going for the technique of storing values specific to
processes (e.g. title, process offerings, data output/input type) in new
data structures/classes corresponding to those in the WPS 0.4.0
specification. Most of the classes are done already, but since they are
becoming quite large in numbers, I thought I'd mention it here just in
case this is an awful design choice. I believe it is the way to go
though, since if the datastructures are filled in by each Process there
will only need to be one WPSDescTransformer (the exact parallel to for
example WFSCapsTransformer) and one WPSCapsTransformer to for example
to generate output for the DescribeProcess and GetCapabilities request
respectively. The datastructures could be passed to the Transformer from
the process and be written to an XML document as a response to a
request. Some data structures could be reused between those transformers
(specifically the ProcessBrief data structure would be used in both
GetCapabilities and ProcessDescription operations). These data
structures would also serve as a common interface for process providers,
which is nice. The above might be called Alternative 1.
Alternative 2 would be something like each process taking part in
writing metadata output upon requests. The WPSDescTransformer would use
some internal method of each Process (for example handleProcessBrief())
that generates output (with start(); element(); end(); and such) to the
outgoing XML document. This would mean that each process would have to
be a part of the Transformer chain, so that its calls would be forwarded
up the chain. I don't know if this is possible. Alternatively, each
process could be its own Transformer, with complete responsibility for
writing metadata output. In that case, I don't know how one solves the
problem if for example several processes are requested to be described
in a single DescribeProcess request. Would they share the same outgoing
document, is that even possible?
If Alternative 1 and 2 are not used, I guess the a single
WPSCapsTransformer could use a XMLProcessReader (exactly like the
XMLConfigReader reads data from the services.xml into classes WMS and
WFS) to read XML file(s) that contain information about each process.
That XML file could be provided by the Process provider, or a common
processes.xml could be provided, much like the services.xml is provided
for some service metadata (name, abstract, keyword, etc). Reading the
XML file would be done each time a request was received by the WPS.
Repeatedly reading Process metadata from disk would surely be slower
compared to having the Process metadata in memory as data structures. Of
course, reading process metadata from an XML file could be done to
populate the data structures of Alternative 1. It all depends on how
Process providers should provide their processes.
I'm leaning towards Alternative 1, I hope that this is OK (since most of
the classes are already implemented!), but I can change to something
else if, for some reason, that is a very bad design.
Jonas
On Mon, 2006-03-13 at 16:05 -0800, Justin Deoliveira wrote:
Hi Jonas,
Thanks for being understanding. Also, I would like to discuss a possible
way to organize your plugins. So it sounds like you are making progress
anyhow, so why dont keep going on what you have now, and then when you
want to move to 1.4.x we can talk about how you can use spring to manage
your process plugins, modules, etc...
-Justin
Jonas Johansson wrote:
> No need to apologise. I can't really expect that everything should work
> perfectly smooth on a new branch, right? But right now I feel I can't
> spend much more time on setting up Eclipse, so I'll go for the 1.3.0_wps
> until I feel more comfortable again =)
>
> Justin, while debugging, I think I finally understood what you said
> about making a process a plugin, like the validation stuff. I guess you
> were talking about what happens in XMLConfigReader, when wfs gets
> validated. The plugIn directory contains a lot of xml files, each
> pointing to a class. But I don't understand how to actually add a new
> class at run-time. And I looked a bit at how Spring framework uses Beans
> to keep track of instances and interfaces. It seems that the Spring way
> is to use separate files that explains relationships between classes
> (similar to how Factory produces instances). But wouldn't it be awkward
> to have a bunch of extra files on the server to keep track of? I guess
> each process would have its own files that describes how it is
> instantiated etc... I think I read that this is also possible to do in
> code. But if I make each process a plugin, am I not solving this problem
> of keeping track of every instantiated process that the WPS implements?
> Well, I haven't quite figured all of this out yet...
>
> Until I go back to 1.4.x from 1.3.0 I'll just use something simpler to
> test the WPS.
>
> Jonas
>
> Mon, 2006-03-13 at 12:11 +0000, Justin Deoliveira wrote:
>> On another note, I apologize for your trouble with 1.4.x, you are the
>> first developer other then myself to step up and actually try to develop
>> with it so you are serving as somewhat of a guinea pig. I appreciate the
>> persistence and diligence.
>>
>> -Justin
>>
>> Jonas Johansson wrote:
>>> Well, I gave it a try and imported the one project made with eclipseAll
>>> and when that did not work I tried importing them separately, which made
>>> Eclipse complain on missing projects on the classpath, and looking at
>>> the "required projects on the build path" for example wfs, shows stuff
>>> I've never seen before like projects vpf, api and such. This is above my
>>> league...
>>>
>>> I need to get some coding done and I want to be able to debug in
>>> Eclipse, so unfortunately I guess I'll stick to my working 1.3.0_wps
>>> since the code works in 1.4.x, it compiles faster without all the other
>>> stuff in 1.4.x and I can debug with jetty. When it is finished I'll move
>>> it over to 1.4.x.
>>>
>>> Jonas
>>>
>>> On Mon, 2006-03-13 at 01:56 -0800, Justin Deoliveira wrote:
>>>
>>>> I added some docs for running from eclipse:
>>>>
>>>> http://docs.codehaus.org/display/GEOSDOC/Building+with+Eclipse
>>>>
>>>> The short of it is after you have all the plugins in your eclipse
>>>> workspace, create a new Run configuration for the
>>>> org.vfny.geoserver.jetty module, and run the class
>>>> org.mortbay.start.Main in debug mode.
>>>>
>>>> I think what the problem might be that you are not running from the
>>>> jetty module which contains said not found class. Which makes sense
>>>> because for 1.3.0, everything is in the project, for 1.4.x, all the
>>>> jetty stuff has been sucked out in a seperate module.
>>>>
>>>> Give the docs a try and see if it works for you. If lot let us know. If
>>>> need be we can hop on IRC and get things going. However I will ask in
>>>> return that you update the docs :).
>>>>
>>>> -Justin
>>>>
>>>>
>>>>
>>>> Jonas Johansson wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> With geoserver 1.3.0 I was debugging in Eclipse using jetty. Is there a
>>>>> document on what one needs to do to get 1.4.x debugging in Eclipse using
>>>>> jetty? I'm getting
>>>>> java.lang.ClassNotFoundException: org.mortbay.jetty.Server
>>>>> at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
>>>>> at java.security.AccessController.doPrivileged(Native Method)
>>>>> at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>>>>> at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
>>>>> at org.mortbay.start.Main.invokeMain(Main.java:145)
>>>>> at org.mortbay.start.Main.start(Main.java:482)
>>>>> at org.mortbay.start.Main.main(Main.java:90)
>>>>>
>>>>> And I can't figure this one out. I have a partly working (it can
>>>>> generate a response to a WPS GetCapabilities operation)
>>>>> "1.3.0_wps" (that is, GeoServer 1.3.0 source + added WPS) and I'd like
>>>>> to move this over to the 1.4.x branch. When I add the corresponding
>>>>> classes from my working 1.3.0_wps into a project 1.4.x_wps, building
>>>>> with maven works just fine. However, when I deploy the geoserver.war in
>>>>> Tomcat, errors occur. Any ideas why this happens (see below)?
>>>>>
>>>>> Here is a list of what works and what doesn't work when deploying
>>>>> 1.4.x_wps:
>>>>>
>>>>> * The WMS GetCapabilities operation
>>>>> (http://localhost:8080/geoserver/wms?request=GetCapabilities) works.
>>>>>
>>>>> * The WFS GetCapabilities operation
>>>>> (http://localhost:8080/geoserver/wfs?request=GetCapabilities)gives the
>>>>> exception:
>>>>> -
>>>>> <ServiceExceptionReport version="1.2.0"
>>>>> xsi:schemaLocation="http://www.opengis.net/ogc
>>>>> http://localhost:8080/geoserver/schemas//wfs/1.0.0/OGC-exception.xsd">
>>>>> -
>>>>> <ServiceException>
>>>>>
>>>>> javax.xml.transform.TransformerException: Translator error
>>>>> </ServiceException>
>>>>> </ServiceExceptionReport>
>>>>>
>>>>> * The WPS GetCapabilities operation
>>>>> (http://localhost:8080/geoserver/wps?request=GetCapabilities) gives the
>>>>> error:
>>>>> HTTP Status 404 - /geoserver/wps
>>>>> ------------------------------------------
>>>>> type Status report
>>>>>
>>>>> message /geoserver/wps
>>>>>
>>>>> description The requested resource (/geoserver/wps) is not available.
>>>>> ------------------------------------------
>>>>> Apache Tomcat/5.0.28
>>>>>
>>>>> * Browsing to http://localhost:8080/geoserver/welcome.do gives the
>>>>> following error:
>>>>>
>>>>> HTTP Status 404 - Servlet action is not available
>>>>> ------------------------------------------
>>>>> type Status report
>>>>>
>>>>> message Servlet action is not available
>>>>>
>>>>> description The requested resource (Servlet action is not available)
>>>>> is not available.
>>>>> ------------------------------------------
>>>>> Apache Tomcat/5.0.28
>>>>>
>>>>>
>>>>> Jonas
>>>>>
>>>>>
>>>>>
>>>>> -------------------------------------------------------
>>>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>>>>> that extends applications into web and mobile media. Attend the live webcast
>>>>> and join the prime developer group breaking into this new coding territory!
>>>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>>>> _______________________________________________
>>>>> Geoserver-devel mailing list
>>>>> Geoserver-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>>> that extends applications into web and mobile media. Attend the live webcast
>>> and join the prime developer group breaking into this new coding territory!
>>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>>> _______________________________________________
>>> Geoserver-devel mailing list
>>> Geoserver-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
