[
https://issues.apache.org/jira/browse/WINK-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801483#action_12801483
]
Bryant Luk commented on WINK-243:
---------------------------------
So if I'm understanding correctly, this is the order of operations:
1. Resource class is instantiated.
2. Resource object is injected but there are a few context objects that aren't
available yet (so those fields are set to null)
3. The context is then later changed by something to add a few context objects
(i.e. a user handler or something)
4. Your expectation is that the resource instance should have the new context
objects injected (basically going back and re-injecting them)
I don't think we should re-inject the ResourceInstance again. There are a lot
of complications with that such as performance and users changing the
fields/properties themselves in the resource method and expecting that their
changes to be permanent (i.e. we inject an object to a @Context UriInfo field
and a user could change that field's value in the resource method to their
custom UriInfo that delegates calls back to the injected UriInfo; very odd
yes, but this has happened).
However, my suggestion is to inject a proxy instead. The change I believe
should be relatively simple.
In wink-common's org.apache.wink.common.internal.registry.ContextAccessor at
around line 72:
{code}
// return context directly
if (runtimeContext != null) {
try {
return runtimeContext.getAttribute(contextClass);
{code}
to:
{code}
// return context directly
if (runtimeContext != null) {
try {
T instance = runtimeContext.getAttribute(contextClass);
if (instance != null) {
return instance;
}
/*
* if the instance isn't directly available from the
* runtimecontext at this time, inject a proxy instead. This
* allows context attributes to be added after a class is
* instantiated
*/
{code}
So if the context attribute isn't available yet, let the method continue
(there's a block of code already below that would inject a proxy). If anyone
has any comments, please let me know.
> Unable to inject fields once ResourceInstance is initialized
> ------------------------------------------------------------
>
> Key: WINK-243
> URL: https://issues.apache.org/jira/browse/WINK-243
> Project: Wink
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.0
> Environment: Wink 1.0 / JRE 1.6
> Reporter: bharath chinnadurai
>
> Unable to inject fields once ResourceInstance is initialized.
> I get a handle to the the resource instance which is about to be invoked
> using UriInfo.getMatchedResources, which will initialize a new
> ResourceInstance using ObjectFactory which would in-turn inject all
> fields/methods to the resource instance and the resource instance is returned
> back. After this process any sort of field injection to the context is not
> getting reflected in the resource instance. This is because in
> ResourceInstance.getInstanceMethod,
> {code:title=ResourceInstance.java|borderStyle=solid}
> ...
> public Object getInstance(RuntimeContext context) {
> if (instance != null) {
> return instance;
> }
> instance = record.getObjectFactory().getInstance(context);
> return instance;
> }
> ...
> {code}
> As we see if the instance is not null the instance is returned as it is.
> A probable fix could be to call wink common's CreationUtils.injectFields() to
> re-inject the fields which would inject any field that was set to the context
> after the resource class was initialized. The code above would look like,
> {code:title=ResourceInstance.java|borderStyle=solid}
> ...
> public Object getInstance(RuntimeContext context) {
> if (instance != null) {
> try {
> CreationUtils.injectFields(instance,
> record.getMetadata(), context);
> } catch (Exception e) {
> throw new ObjectCreationException(e);
> }
> return instance;
> }
> instance = record.getObjectFactory().getInstance(context);
> return instance;
> }
> ...
> {code}
> However this would re-inject fields that was already injected to the instance
> before while creation of the instance. If that can be lived with, this could
> possibly be a patch for this bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
