Paul
Many thanks for this, it is very helpful! I see there's a lot of
flexibility here. Initial observation is that I was unsure of the use of
@Path("/")within the pattern matching algorithm. Just rereading the
algorithm (in JAX-RS 4Dec2007 section 2.5) it now makes more sense.
Taking your first sample:
@Path("/")
public class VirtualRoot {
@Path("virtual-res1")
public Object getVirtualRes2() { ... }
@Path("virtual-res2")
public Object getVirtualRes2() { ... }
}
@Path("atomic-res1")
public class Atomic { ... }
I now understand that the matching algorithm would locate "atomic-res1"
before falling back to "/" as a final pattern (i.e. being the shortest
root resource regex in the set). As such I can declare as many concrete
root resources with arbitrary sub-resource hierarchies, all of which
will be enumerated ahead of the "/" VirtualRoot selector being hit. As
such my virtual (root) resources can then be managed through a single
class hierarchy encapsulating the back-end integration stuff I need for
these types. Good.
In terms of the options you've put on the table, as you suggest I am
initially going to stick with sub-resource locators as I can't rely on
any commonality in resource naming conventions (i.e. my
virtual-res{1..n} is somewhat misleading as my VR's will be of arbitrary
names such as usage, faults, assets...). As such I will run with option
1 first and see how I can flex that as my understanding increases.
Many thanks again for your assistance.
Stew
Stewart Welbourne
stewart.welbourne_at_bt.com
-----Original Message-----
From: Paul.Sandoz_at_Sun.COM [mailto:Paul.Sandoz_at_Sun.COM]
Sent: 11 January 2008 12:27
To: Welbourne,S,Stewart,DLL R
Subject: Re: Multiple UriTemplate Annotations for Generic 'Handler'
Classes?
Hi Stew,
If you want an explicit dynamic solution you can do the following:
@Path("/")
public class VirtualRoot {
@Path("virtual-res1")
public Object getVirtualRes2() { ... }
@Path("virtual-res2")
public Object getVirtualRes2() { ... }
}
@Path("atomic-res1")
public class Atomic { ... }
Or follow Marc's proposal of a non-explicit dynamic solution:
@Path("/")
public class VirtualRoot {
@Path("virtual-{res}")
public Object getVirtualRes2(@PathParam("res") String r) { ... }
// Note that @UriParam was renamed to @PathParam
// but only for 0.6 onwards, so is not in the 0.5 release of Jersey
}
@Path("atomic-res1")
public class Atomic { ... }
Thus you don't have to use a 'virtual' parent path.
A non-dynamic explicit way to do this is to have an abstract class from
which you extend, as follows:
public class AVR {
// HTTP methods on AVR class
}
@Path("virtual-res1")
public class VirtualResource1 extends ARV {}
@Path("virtual-res2")
public static class VirtualResource1 extends ARV {}
@Path("atomic-res1")
public class Atomic { ... }
Or a non-dynamic implicit way:
@Path("virtual-{res}")
public class VirtualResource {
public VirtualResource(@PathParam("res") String r) { ... }
}
@Path("atomic-res1")
public class Atomic { ... }
I suspect that sub-locators is the way for you to go to return something
dynamic based on looking up what the virtual resource is. This allows
different virtual resources to have different methods and URI spaces
(you could even download such resources classes from the network!).
Hope this helps,
Paul.
stewart.welbourne_at_bt.com wrote:
>
> Marc
> many thanks for your concise response - I feel pretty comfortable that
> there is a 'technical' capability to address my particular
requirement.
> As such I see how I can get the level of control I need but I'm
> concerned about the potential implications for my 'clean' namespace.
> For example if I have say 3 root resources in my public resource
> namespace (those published to my clients as part of their interface
> contract), one of which has a concrete representation and two of which
> have a dynamically assembled representation as follows:
>
> ___http://res.domain.com/atomic-res1_ //served directly from an
> atomic datasource via entity class
> _http://res.domain.com/virtual-res2_ //assembled via back-end
> integration _http://res.domain.com/virtual-res3_ //assembled via
> back-end integration
>
> Then are you suggesting that I would need to inject a root 'branch' to
> explicitly segregate the 'virtuals' in order to exploit the capability
> you've outlined along the lines of:
>
> /atomic-res1
> /virtual/virtual-res2
> /virtual/virtual-res3
> ...
>
> Such that I would have something like this:
>
> @Path("/atomic-res1") /
> public class AtomicResource1 {
> //standard O/R based represnetation production }
>
>
>
> @Path("/virtual")
> public class VirtualResourceRouter {
> @Path("{resource}")
> public Object resolve(@PathParam("resource") String resource) {
> if (resource.equals("virtual-res2")
> return new VirtualResource2(...);
> else
> return new VirtualResource3(...);
>
> }
> }
>
> So whilst I understand how this can work - I introduce
> technology-induced padding into my resource namespace which I'm
> attempting to keep clean and meaningful. This may seem like a small,
> cosmetic observation but purity in the namespace is an area of great
> sensitivity in our work to date.
>
> Sitting back and thinking about this (for the sake of argument) I'm
> thinking I 'could' technically push all my root resources via this
> front-end router (rooter :-) but that's sort of working against the
> benefits of the scheme. On the other hand, unless I've misinterpreted
> you, my published namespace is gonna be impacted - where my ideal
> scenario means I could add my two virtual root resources
"/virtual-res2"
> and "/virtual-res3" @Path annotations to the router class without
> impacting my URI scheme.
>
> Thanks
> Stewart
>
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
For additional commands, e-mail: users-help_at_jersey.dev.java.net