On Apr 24, 2007, at 12:31 PM, Paul Sandoz wrote:
>
>> -------
>> This reminds me: does the API so far include a standard way to
>> access container configuration (for the handler classes to access
>> configuration time parameters)?
>>
>
> By configuration time parameters do you mean the annotations?
>
Or perhaps something like servlet parameters when running in a
servlet container ? For this case we could either define some generic
API and define a mapping from that to each container or support some
kind of injection of a container-specific context. I lean towards the
latter approach right now as being more flexible at the risk of tying
an application to particular container. An example of the latter
would be something like:
@UriTemplate("...")
public class SomeResource {
@Resource
ServletConfig config;
public SomeResource() {
for (Enumeration e = config.getInitParameterNames() ;
e.hasMoreElements() ;) {
...
}
}
...
}
Marc.
> Paul.
>
>> Talk to you in about an hour...
>> Thanks,
>> Jan
>> On 24.04.2007, at 14:06, Paul Sandoz wrote:
>>> Jan Algermissen wrote:
>>>> Hi Paul,
>>>> maybe i am missing something, but I do not see how e.g. the
>>>> InvoiceResource is matched on a request URI?
>>>
>>> InvoicesResource refers statically to InvoiceResource using the
>>> SubResource annotation:
>>>
>>> @UriTemplate("/invoices")
>>> @SubResources({InvoiceResource.class})
>>> class InvoicesResource { ... }
>>>
>>> @UriTemplate("{invoice_Id}")
>>> class InvoiceResource { ... }
>>>
>>>
>>> Thus the URI path to InvoiceResource is:
>>>
>>> /invoices/{invoice_Id}
>>>
>>> i.e. the coalescing of the templates.
>>>
>>> It is presented as steps 1 and 2 in the example table. I should
>>> have put the Java classes in the table as well as it might have
>>> made things a little clearer.
>>>
>>>
>>>> Something else:
>>>> I think that the actual paths (e.g. /invoice) are a
>>>> configuration time issue and that dispatching from a request URI to
>>>> a handler class should be done by a seperate component; it
>>>> should not be part of the handler classes' source code
>>>> (even if it's just an annotation).
>>>
>>> This was an explicit design decision. We did not want to separate
>>> out these things and wanted to keep the object model closely
>>> related to the URI path hierarchy. See stapler [1] for more
>>> rational.
>>>
>>>
>>>> Suppose I hand the class files for the code below to someone
>>>> else that really does not want the path to be '/invoices'; what
>>>> then?
>>>>
>>>
>>> This is not supported. (But i suppose it is possible to support
>>> such aliasing in an underlying container by mapping between URI
>>> paths.)
>>>
>>> Is it not the case that the designer of the Web application
>>> usually controls the URI space and the relationship between
>>> resources in that URI space?
>>>
>>> In your experience how common a use-case would it be that the URI
>>> templates would require changing while still keeping the Web
>>> application consistent for the relationships between the resources?
>>>
>>>
>>> For the Web application there are relationships between resources
>>> that need to be maintained: between invoices and invoice, invoice
>>> and deliveries, invoice and payments etc. Thus when considered as
>>> a whole thing needs to interconnect. We chose a design where this
>>> interconnection is part of the resource POJOs themselves so:
>>>
>>> - the relationships between POJOs are not separated out into
>>> two different places, there is only one place;
>>>
>>> - related application logic need not be duplicated and/or
>>> distributed;
>>>
>>> - POJOs can be intuitively reused without having to do
>>> any configuration in a separate location; and
>>>
>>> - POJOs can be polymorphic. For, example an invoice could be
>>> polymorphic and specialized without having to break the contract
>>> between invoices and invoice or invoice and deliveries etc.
>>>
>>> Namely we have tried to take existing and familiar Java/OO
>>> concepts so that it is 'as natural as possible' to develop
>>> RESTful Web applications using just plain old Java objects.
>>>
>>>
>>> From our experience with stapler/hudson it is often the case that
>>> application logic can be associated quite closely with a bunch of
>>> resources. For example in Hudson there is the concept of a job
>>> that has a list of builds so the following URI paths interrelate
>>> for job and builds:
>>>
>>> job/my-job/ // get all the builds
>>> job/my-job/buildTimeTrend // get a build time history as an
>>> image
>>> job/my-job/lastBuild // get the last successful build
>>> job/my-job/{build} // get a specific build
>>>
>>> Having such relationships split up in my experience can increase
>>> the number of Java classes and/or make it harder to implement and
>>> maintain the application logic. As a further example the Hudson
>>> root resource has at least 20 different sub-resources that
>>> interrelate in application logic to various degrees with the
>>> super resource. IMHO as such relationships start to grow having
>>> to maintain things in separate places starts to become very
>>> unwieldy.
>>>
>>> Paul.
>>>
>>> [1] https://stapler.dev.java.net/what-is.html
>>>
>>> --| ? + ? = To question
>>> ----------------\
>>> Paul Sandoz
>>> x38109
>>> +33-4-76188109
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
> --
> | ? + ? = To question
> ----------------\
> Paul Sandoz
> x38109
> +33-4-76188109
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s