Hi RJ,
Judson, Ross wrote:
> Between 0.4 and 0.5 we lost the ability to simply give Message providers
> as a parameter to the container factory, and switched to using a
> metafile registry.
>
Oh, sorry about that.
For the releases up to and including 0.5 we always intended that the
META-INF services was the public interface for the registration of
message providers.
For 0.6 this is changing (see attached email i recently sent).
It has been a while that i have looked at the 0.4 code... i am not
actually sure how you managed override the use of the providers in 0.4
(and not use <META-INF/services) and what broke for you in 0.5. Could
you explain a little as it would help me better understand your use-case?
> The default JAXB support is too limited; I am not sure if it can cope
> with polymorphic classes that are not statically reachable from the seed
> class (to get around this all necessary "root" classes have to be
> provided to the JAXB context constructor).
>
I agree, we are going to try and improve this.
The current approach we are proposing is for the developer to provide
one or more JAXB context resolver:
@Provider
JAXBContextResolver implements ContextResolver<JAXBContext> {
public JAXBContext getContext(Class<?> objectType) {
...
}
}
the runtime will detect these and aggregate them into one that defers to
the 'n' application defined instances. Then the aggregated instance can
be injected onto a JAXB message body reader/writer:
@Provider
public class JAXBReader implements JMessageBodyReader<Object> {
@HttpContext
private ContextResolver<JAXBContext> resolver;
...
}
and it can use the resolver to determine what context to use.
Provider classes (anything annotated with @Provider) will be registered
via the ResourceConfig like for root resource classes. So you can define
your own ResourceConfig impl (or reuse the DefaultResourceConfig and add
the provider classes, for example) or use one supplied by Jersey to scan
for provider and root resource classes.
There will be a set of core message providers supplied by the runtime
but it should be possible to override these with user supplied message
providers.
The runtime will only be aware of a limited set of service interfaces
associated with providers. We don't want to re-create an IoC framework,
and if developers need more advanced use they will be able to utilize an
IoC framework like Spring or Guice for more complete injection and
dependency support. We will be making it so that providers can be
instantiated by an IoC framework.
> Using meta-inf removes type safety and is fraught with errors and
> classpath issues. I am not sure what issues this switch was intended to
> fix; perhaps they could be listed.
As i said we never switched from 0.4 to 0.5 to using META/services, it
was always used.
> Why was it problematic to simply
> provide services to the container, and why is it limited to declared web
> services now?
>
What do you mean by 'declared web services' ?
Is what i described above (and in the attached email) something that
could meet your requirements? since I am in the process of developing
all these changes your feedback (and others) on this would be most helpful.
> I'd like to be able to mark any implementation of a service with
> @Provider. Better would be the ability to refine the type of the
> provider in the annotation (@Provider(SomeService.class)), then have
> runtime checking to verify that the object actually provides the
> specified service. If SomeService is a parameterized type, the actual
> class passed in can be introspected to fully qualify the service
> category.
>
Could you give an explicit code example of what you would like to see
from a developer perspective? I am not sure if what i described fits in
with most of what you described above?
Thanks,
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109
attached mail follows:
Hi,
Injection of @HttpContext or @Resource stuff is now supported on message
body readers/writers. So it is now possible to inject, say UriInfo, like
one can on a resource class.
Readers/writers are instantiated within the scope of the web application
(previously they were statically scoped per the class loader).
Next up: scan for readers/writers like we scan for resource classes,
thus META-INF services will no longer be required for registration.
After that: support a JAXB context resolver, one or more of which may be
implemented by the application, and an aggregation can be injected onto
a reader/writer or resource class. This will enable the application to
declare JAXB contexts.
And after that: enable deferring instantiation of readers/writers/jaxb
resolvers/resource config etc to an IoC framework.
Paul.
--
| ? + ? = 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