Jo Størset wrote:
> Ok, am not quite sure I will need the implicit feature. And I think I
> may be following your logic, but I must admit I still don't quite get
> where the logic that implicitly maps to the jsp templates in bookstore
> but not to my ftl ones are hidden. The viewablerule should treat my
> template processor the same as the jsp one, so maybe I need to
> understand the rule matching better?
>
Not sure if below helps to explain things...
Here is the rules structure for a resource class:
Combining rules
Atomic rules
Rules for processing according to 311 specification
Sequential rules
Implicit viewable rule for a path segment
Implicit viewable rule end of path
Terminating rule for a path segment
Terminating rule for end of path
The atomic rules will match at most one rule, and therefore accept at
most one rule.
The sequential rules will match zero or more rules in sequence and
accept at most one rule (the first in the sequence that is accepted).
The combining rules will match/accept the atomic rules, if there is no
match, or if there is a match but it is not accepted, then it will move
on to the sequential rules.
This is the reason that a HTTP method overrides the behavior for the
viewable rules. Because the atomic rule finds a match that is also
accepted (HttpMethodRule) so no further rules are processed. Notice that
the Bookstore classes do not have any HTTP methods (using @GET).
>>> I attached the processor, in case it tells you anything.
>>>
>>> <FreemarkerTemplateProcessor.java>
>>
>> Nice, very compact. All looks OK. You might be able to put the
>> initialization code in the constructor and avoid the synchronized init
>> method and the null check in the resolve method.
>
> Your're right. It was actually a downsized version of an earlier spring
> assembled prototype, and I think I will go in the spring direction when
> I need a more complete version (to enable proper configuration).
>
> I've made a sample xslt version as well, and it works fine. The template
> provider does the jaxb marshalling itself.
Great!
> I'm a bit worried this might
> be a problem if the default jaxb context and this provider's context
> differs, since it's important to have a well defined and viewable xml to
> transform. Do you see any potential problems here, is it easy to get
> access to the standard jaxb context from this provider?
>
Have a look at:
com.sun.ws.rest.impl.provider.entity.AbstractJAXBElementProvider
for getting access to user defined JAXB contexts for JAXB types.
You could potentially reuse the existing JAXB message body writer if you
serialize the JAXB object to an OutputStream:
@Context MessageBodyContext mbc;
... {
MessageBodyWriter mbw = mbc.getMessageBodyWriter(type, null)
mbw.writeTo(t, null, null, out);
}
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109