This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 247930 - Allow RequestProcessor to propagate default Lookup.
Summary: Allow RequestProcessor to propagate default Lookup.
Alias: None
Product: platform
Classification: Unclassified
Component: Lookup (show other bugs)
Version: 8.1
Hardware: All All
: P1 normal (vote)
Assignee: Jaroslav Tulach
Depends on:
Reported: 2014-10-14 16:08 UTC by Tomas Zezula
Modified: 2014-10-29 11:43 UTC (History)
2 users (show)

See Also:
Issue Type: TASK
Exception Reporter:

Introducing Lookups.execute - please review. (19.22 KB, patch)
2014-10-15 15:28 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Zezula 2014-10-14 16:08:58 UTC
Allow RequestProcessor to propagate default Lookup.
In case the thread submits a request to the RequestProcessor the thread context should be propagated to the RequestProcessor thread.
Comment 1 Jaroslav Tulach 2014-10-15 13:46:58 UTC
I have good experience with BrwsrCtx from the HTML/Java API:
It has a method to get the current context and also change the context for the time when provided code is being executed. It seems to work OK.

Based on that experience I think we should introduce

public static void Lookups.execute(Lookup globalLookup, Runnable r);

which could be used by clients (like a servlet handling a request) to associate own lookup with currently executing code. Moreover the RequestProcessor would be modified to remember the Lookup at the time of posting a request and use the execute method before starting the task in the other thread.
Comment 2 Jaroslav Tulach 2014-10-15 15:28:21 UTC
Created attachment 149924 [details]
Introducing Lookups.execute - please review.

One question I am not sure about is whether we should really change the instance returned from Lookup.getDefault() or always return a proxy of Lookup.getDefault() and only change its content.
Comment 3 Tomas Zezula 2014-10-15 16:24:40 UTC
Seems good to me.
In the java4tailwind we have ExecutionContext.executeWith() method similar to the Lookups.execute and we change the default lookup instance. We can try to simply change the instance we can change it later on.
Comment 4 Svata Dedic 2014-10-15 16:36:14 UTC
(In reply to Jaroslav Tulach from comment #2)
> One question I am not sure about is whether we should really change the
> instance returned from Lookup.getDefault() or always return a proxy of
> Lookup.getDefault() and only change its content.

I've faced similar decision in server_split branch, and decided to go with multiple Lookup.getDefault() instances. The reason was that each instance was specific to the Lookup.getDefault() caller's context (whatever the context is) and the caller may save it for later processing in a different thread or so. Combined with executeWith() the saved context can be re-established - e.g. a code acting on behalf of an user etc.
Comment 5 Jaroslav Tulach 2014-10-16 06:28:24 UTC
OK. Let's stick with changing instances. The success of my change would be, if you can remove your own executeWith and use Lookups.execute directly. Btw. if you want I can change the name of the method to executeWith so you have easier migration path ;-)
Comment 6 Tomas Zezula 2014-10-16 07:47:33 UTC
No need to call it "executeWith" as we have single usage of this method so far.
Comment 7 Jaroslav Tulach 2014-10-20 11:41:30 UTC
Unless there are objections, let's integrate on Wednesday.
Comment 8 Tomas Zezula 2014-10-20 12:07:04 UTC
Thanks Jardo!
Comment 9 Jaroslav Tulach 2014-10-22 08:16:21 UTC
At the end I go with Lookups.executeWith. The original patch needed more tweaks, as it deadlocked. Hopefully, after 30ab399d18aa the build with succeed.
Comment 10 Quality Engineering 2014-10-29 11:43:34 UTC
Integrated into 'main-silver', will be available in build *201410290913* on (upload may still be in progress)

User: Jaroslav Tulach <>
Log: #247930: Lookups.executeWith(...)