On Oct 15, 2008, at 5:50 PM, Matthieu Riou wrote:
> On Wed, Oct 15, 2008 at 8:26 AM, Paul Sandoz <Paul.Sandoz_at_sun.com>
> wrote:
> Hi Matthieu,
>
> How will you determine from a business process what the URIs, HTTP
> methods and representations for resources of that process are?
>
> The URIs and methods for the processes are predefined so even if I
> don't know about the process yet, I know what the URL and methods
> are going to be like once I see the process (basically from its name
> and starting activity). Depending on the process implementation, new
> resources can then be created at runtime and their URIs,
> methods, ..., are defined by the process itself, depending on the
> process constructs used.
>
OK.
>
> One way this can be done is for the business processes to provide
> resource classes themselves are returned by a sub-resource locator
> of a root resource (such classes are analyzed at runtime). It is
> also possible to dynamically reload root resource classes.
>
> If there is a common pattern to all business process you can write
> general resource classes with careful use of URI templates e.g.
> @Path("{id}"}
>
> I think I can work with the assumption of having a process engine
> level root resource, processes being sub-resources and process
> execution related resource being sub-sub-resources. Only the second
> and third level resources would need to be dynamic (we don't
> instantiate several engines). Does that sound possible?
I think something is possible here, for example the sub-resource
locator of the engine could do:
@Path("{process}")
public Object getProcess(@PathParam("process") String process) {
Object o = ProcessEngine.lookup(process);
if (o == null) throw NotFoundException();
return o;
}
> On thing I forgot to mention is that sub-resources would need to be
> removable as processes can get undeployed.
This is an area that requires some work. There needs to be a way to
say "please remove all information about and references to these
components that you may know about)". I can add support for that. But
it may work for sub-resources since it is the application that
decides, the issue is Jersey will retain references to the sub-
resource classes, which may not be good.
Are the class definitions and/or implementations for processes likely
to change over redeployment?
> Also would you have an example of reloading a root resource class?
>
See here [1]. Currently the reloading functionality reloads the whole
Jersey app. I need to work on a more granular level.
In general this area is non-trivial for frameworks that leverage and
cache reflection information and store references. One area that
might be useful to investigate here is using OSGi to manage the
notification of loading/unloading of modules that contain JAX-RS/
Jersey components. To me leveraging OSGi seems like the right thing to
do in general here.
Paul.
[1]
http://markmail.org/search/?q=list%3Anet.java.dev.jersey.users+ContainerNotifier#query
:list%3Anet.java.dev.jersey.users%20ContainerNotifier+page:1+mid:ztw4htppadrxh2rj+state:results
> Thanks!
> Matthieu
>
>
> Paul.
>
>
> On Oct 15, 2008, at 5:13 PM, Matthieu Riou wrote:
>
> Hi,
>
> I have a need to create resources dynamically instead of having
> predefined static classes. The use case is I'm implementing a server
> where users can deploy business processes. Those should be exposed
> using a RESTful web service. But of course I don't know beforehand
> the resource address or even how many resources I'm going to have.
>
> Is there an API in Jersey that I could use to handle this use case?
>
> Thanks,
> Matthieu
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>