Re: [deegree-devel] Extension processes for WPS in deegree3

[Stefan K. <ste...@tu...>]

Hello again,
> You are right, processlets *need* to be thread-safe (and we must make 
> this very clear in the documentation). But this is
> not necessarily bad (the same applies for servlets) and it also has a 
> clear advantage. BTW, the processlet interface was
> designed with the (well-tested) Servlet interface in mind:
>
> a) A Servlet is a piece of code that can be accessed via HTTP methods.
> b) A Processlet is a piece of code that can be accessed via the 
> WPS-Execute protocol.
>
> Besides being based on a proven concept, I see the main benefit of the 
> current approach (one Processlet instance per
> Process type) in its clarity with respect to the lifecycle of 
> Processlet objects: init() and destroy() are just called
> once. If you had multiple instances, would you want init() to be 
> called multiple times?
> Maybe we could just add an abstract base class (e.g. 
> ThreadSafeProcesslet) on top of the current concept that takes care
> of initializing a new instance for each execute request and just calls 
> another method, e.g. #executeSafe(...).
>
> What do you think 
Your point is clear. I guess there are just different views on that and 
they all have advantages and disadvantages. I can live with the analogy 
of a Servlet and a Processlet. If you want to provide a thread-safe 
implementation I would not put that code into the Processlet class (or a 
parent class), but provide a configuration option.
> Thanks for the explanation. We're still thinking about the best way to 
> package process definitions and processlets
> implementations for deploying dynamically, e.g. through a web 
> management console or a hot-deployment directory.
> Obviously, they could be packaged in a JAR. Of course, we would have 
> to provide our own classloader for dynamically
> instantiating the Processlet class. Do you think this works easier / 
> better if we would just use OSGI bundles for that?
Definately. You get the classloader with plug-in scope for free. The 
overhead of OSGI is not that big, and it is possible to deploy an 
OSGI-framework in an application server 
(http://eclipse.dzone.com/articles/embedding-osgi-tomcat). A 
hot-deployment directory also exists in some implementations (e.g. 
http://felix.apache.org, "fileinstall" bundle).

When looking at the code I noticed that the process execution state is 
only updated once after the process has started and once after the 
process() method returns. This way the progress monitor is not really 
useful. It is also not possible to report intermediate results of a 
long-running simulation to the user.

Best regards,
Stefan