[Geoserver-devel] Going back to scripted process status handling: can we make it easier?

Hi,
going back to scripted process status handling, I was looking at the ProgressListener interface,
and… well, it sort of pains me to pass that to scripts, since it’s really more complex than it should
be.

How about the following object, that would wrap a ProgressListener, instead?

public class ProcessStatus {
ProgressListener listener;

public ProcessStatus(ProgressListener listener) {
super();
this.listener = listener;
}

public ProgressListener getListener() {
return listener;
}

public void setStatus(float progress) {
listener.progress(progress);
}

public void setTask(String status) {
listener.setTask(Text.text(status));
}

public void throwException(String message) {
throw new WPSException(message);
}

public void throwException(String message, String code) {
throw new WPSException(code, message);
}

public void throwException(String message, String code, String locator) {
throw new WPSException(message, code, locator);
}
}

It’s as simple as possible, and does everything that WPS cares for.
Just wondering if having overloaded methods for throwException might cause issues with
scripting languages.

And oh, the exception being thrown inside throwException in the real implementation
might be one of those that directly set message, code and locator in the
generated OGC exception report, if the process wants to use a normal output
I guess it could just use its own native exception throwing right?

Let me know how it looks.

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


I don’t mind simplification, I think I have a copy I prepared for the JTS library a while back (which was not accepted because martin is busy).

I would prefer to set up something simple that is not WPS specific…

···

Jody Garnett

On Mon, Jun 9, 2014 at 7:21 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
going back to scripted process status handling, I was looking at the ProgressListener interface,
and… well, it sort of pains me to pass that to scripts, since it’s really more complex than it should
be.

How about the following object, that would wrap a ProgressListener, instead?

public class ProcessStatus {
ProgressListener listener;

public ProcessStatus(ProgressListener listener) {
super();
this.listener = listener;
}

public ProgressListener getListener() {
return listener;
}

public void setStatus(float progress) {
listener.progress(progress);
}

public void setTask(String status) {
listener.setTask(Text.text(status));
}

public void throwException(String message) {
throw new WPSException(message);
}

public void throwException(String message, String code) {
throw new WPSException(code, message);
}

public void throwException(String message, String code, String locator) {
throw new WPSException(message, code, locator);
}
}

It’s as simple as possible, and does everything that WPS cares for.
Just wondering if having overloaded methods for throwException might cause issues with
scripting languages.

And oh, the exception being thrown inside throwException in the real implementation
might be one of those that directly set message, code and locator in the
generated OGC exception report, if the process wants to use a normal output
I guess it could just use its own native exception throwing right?

Let me know how it looks.

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it



HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

On Mon, Jun 9, 2014 at 12:04 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

I don't mind simplification, I think I have a copy I prepared for the JTS
library a while back (which was not accepted because martin is busy).

I would prefer to set up something simple that is not WPS specific...

Hem... do you realize I mean to send that class only to WPS scripted
processes, e.g., wps processes
written in jython, javascript, and so on?

The Java ones would be unaffected, as well as anything else already using
ProgressListener

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

I did, but would like to look at simplification for the Java developers as well.

I expect the scripted processes may also need their own implementations of “sub progress listener” etc…

···

Jody Garnett

On Mon, Jun 9, 2014 at 8:08 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Jun 9, 2014 at 12:04 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I don’t mind simplification, I think I have a copy I prepared for the JTS library a while back (which was not accepted because martin is busy).

I would prefer to set up something simple that is not WPS specific…

Hem… do you realize I mean to send that class only to WPS scripted processes, e.g., wps processes
written in jython, javascript, and so on?

The Java ones would be unaffected, as well as anything else already using ProgressListener

Cheers

Andrea

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


On Mon, Jun 9, 2014 at 12:12 PM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

I did, but would like to look at simplification for the Java developers as
well.

Have no mandate to work on it. This would have to be done in GeoTools I
guess, since the
code passing down listeners to processes is there. Want to work on it?

I expect the scripted processes may also need their own implementations of
"sub progress listener" etc..

This is exactly what I'm trying to propose, a script specific one

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

You miss understood me slighty, once you have the interface I expect scripts will need to be able to refine their work as we do with sub process listeners. So if the script wants to be broken into several methods, they can pass a process listener in responsible for a section of the work.

···

Jody Garnett

On Mon, Jun 9, 2014 at 8:18 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Mon, Jun 9, 2014 at 12:12 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

I did, but would like to look at simplification for the Java developers as well.

Have no mandate to work on it. This would have to be done in GeoTools I guess, since the
code passing down listeners to processes is there. Want to work on it?

I expect the scripted processes may also need their own implementations of “sub progress listener” etc…

This is exactly what I’m trying to propose, a script specific one

Cheers

Andrea

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


On Mon, Jun 9, 2014 at 3:00 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

You miss understood me slighty, once you have the interface I expect
scripts will need to be able to refine their work as we do with sub process
listeners. So if the script wants to be broken into several methods, they
can pass a process listener in responsible for a section of the work.

Hmmm... not sure what sub-listeners are then. Don't think we have any
processes, scripted or java, using
that approach (althought I think I understand what you would use them for).

It seems to me we are getting out of topic... are you telling me we cannot
allow scripts to handle state
and exceptions unless these sub-listeners are done first? Or else, why are
we talking about them in
this thread?

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

The interface looks good to me. Overloading with a different number of arguments shouldn’t cause any issue at all afaik, it’s cases where methods are overloaded with same number of arguments but different types that i have run into problems before.

···

On Mon, Jun 9, 2014 at 3:21 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
going back to scripted process status handling, I was looking at the ProgressListener interface,
and… well, it sort of pains me to pass that to scripts, since it’s really more complex than it should
be.

How about the following object, that would wrap a ProgressListener, instead?

public class ProcessStatus {
ProgressListener listener;

public ProcessStatus(ProgressListener listener) {
super();
this.listener = listener;
}

public ProgressListener getListener() {
return listener;
}

public void setStatus(float progress) {
listener.progress(progress);
}

public void setTask(String status) {
listener.setTask(Text.text(status));
}

public void throwException(String message) {
throw new WPSException(message);
}

public void throwException(String message, String code) {
throw new WPSException(code, message);
}

public void throwException(String message, String code, String locator) {
throw new WPSException(message, code, locator);
}
}

It’s as simple as possible, and does everything that WPS cares for.
Just wondering if having overloaded methods for throwException might cause issues with
scripting languages.

And oh, the exception being thrown inside throwException in the real implementation
might be one of those that directly set message, code and locator in the
generated OGC exception report, if the process wants to use a normal output
I guess it could just use its own native exception throwing right?

Let me know how it looks.

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it



HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

Hey Andrea:

I checked with Martin and he no longer has my patch (it differed from yours in that it had sublisteners, calculated work, and did not have exemption handling). Different definitions of what is simple I guess.

Out of that list the only one that may be in scope for you is calculating work - here is the thought…

I have found the setProgess( float ) to be a real pain for implementors - since they are stuck keeping their own “total” and counter and converting it to a percentage to pass in for our listener.

With that in mind I recommend taking that burden away - something along the lines of:

public void start(String status, int total) {
listener.setTask(Text.text(status));
this.total = total;
this.work = 0;
}

public void work( int worked ){
work += worked;
listener.progress( (float) work / (float) total);
}

···

Jody Garnett

On Mon, Jun 9, 2014 at 7:21 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
going back to scripted process status handling, I was looking at the ProgressListener interface,
and… well, it sort of pains me to pass that to scripts, since it’s really more complex than it should
be.

How about the following object, that would wrap a ProgressListener, instead?

public class ProcessStatus {
ProgressListener listener;

public ProcessStatus(ProgressListener listener) {
super();
this.listener = listener;
}

public ProgressListener getListener() {
return listener;
}

public void setStatus(float progress) {
listener.progress(progress);
}

public void setTask(String status) {
listener.setTask(Text.text(status));
}

public void throwException(String message) {
throw new WPSException(message);
}

public void throwException(String message, String code) {
throw new WPSException(code, message);
}

public void throwException(String message, String code, String locator) {
throw new WPSException(message, code, locator);
}
}

It’s as simple as possible, and does everything that WPS cares for.
Just wondering if having overloaded methods for throwException might cause issues with
scripting languages.

And oh, the exception being thrown inside throwException in the real implementation
might be one of those that directly set message, code and locator in the
generated OGC exception report, if the process wants to use a normal output
I guess it could just use its own native exception throwing right?

Let me know how it looks.

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it



HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Hi all,
here is the pull request:

https://github.com/geoserver/geoserver/pull/615

The object passed down is called StatusMonitor, and to figure
out if the script wants to use it, I’ve followed a convention approach, if an input is called
“monitor”, then it will receive the progress listeners (and won’t be advertised as a public
input), as this allows all scripting languages to play ball.

The other approach would have been to have a monitor=true entry in the input parameter
metadata, but it would have been possible to use the status monitor from python only.

Also see how the exceptions being throw by scripted processes get glazed two times
before the wps can see them, which is not too nice to the script writer imho: in the end,
processes should be considered somewhat similar to servlet, with the WPS
working as a container, so at least in the long run we should give process implementors
as much control as possible to the outputs, if they want to exercise it, of course
(and here is where that special exception in the other threads gets into the picture)

Feedback/review welcomed

Cheers
Andrea

···

On Tue, Jun 10, 2014 at 2:57 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Hey Andrea:

I checked with Martin and he no longer has my patch (it differed from yours in that it had sublisteners, calculated work, and did not have exemption handling). Different definitions of what is simple I guess.

Out of that list the only one that may be in scope for you is calculating work - here is the thought…

I have found the setProgess( float ) to be a real pain for implementors - since they are stuck keeping their own “total” and counter and converting it to a percentage to pass in for our listener.

With that in mind I recommend taking that burden away - something along the lines of:

public void start(String status, int total) {
listener.setTask(Text.text(status));
this.total = total;
this.work = 0;
}

public void work( int worked ){
work += worked;
listener.progress( (float) work / (float) total);
}

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


Jody Garnett

On Mon, Jun 9, 2014 at 7:21 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
going back to scripted process status handling, I was looking at the ProgressListener interface,
and… well, it sort of pains me to pass that to scripts, since it’s really more complex than it should
be.

How about the following object, that would wrap a ProgressListener, instead?

public class ProcessStatus {
ProgressListener listener;

public ProcessStatus(ProgressListener listener) {
super();
this.listener = listener;
}

public ProgressListener getListener() {
return listener;
}

public void setStatus(float progress) {
listener.progress(progress);
}

public void setTask(String status) {
listener.setTask(Text.text(status));
}

public void throwException(String message) {
throw new WPSException(message);
}

public void throwException(String message, String code) {
throw new WPSException(code, message);
}

public void throwException(String message, String code, String locator) {
throw new WPSException(message, code, locator);
}
}

It’s as simple as possible, and does everything that WPS cares for.
Just wondering if having overloaded methods for throwException might cause issues with
scripting languages.

And oh, the exception being thrown inside throwException in the real implementation
might be one of those that directly set message, code and locator in the
generated OGC exception report, if the process wants to use a normal output
I guess it could just use its own native exception throwing right?

Let me know how it looks.

Cheers
Andrea

==

GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.

==

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it



HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://www.hpccsystems.com


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel