jsr236-experts@concurrency-ee-spec.java.net

[jsr236-experts] Re: New ContextService API proposal from JSR 359 spec lead

From: Nathan Rauh <naterauh_at_us.ibm.com>
Date: Tue, 22 Jan 2013 14:00:57 -0600

Anthony/Binod,

I'm not sure I see the need for a new method that adds a ContextHint
capability. Execution properties should already allow for this, apart
from the requirement that execution properties always be String values
whereas the ContextHint in the example has some other custom type (
ContainerSpecificContextObject).

Here's an example with the existing ContextService interfaces,

  Map<String, String> hints =
Collections.singletonMap("com.mycompany.hints.MY_HINT_1", hint);
  Runnable rProxy = ctxService.createContextualProxy(myRunnableInstance,
hints, Runnable.class);
  Future f = execSvc.submit(rProxy);

  ...
  hint =
ctxService.getExecutionProperties(myRunnableInstance).get("com.mycompany.hints.MY_HINT_1");

I would be open to allowing data types other than String from execution
properties, provided those other types are serializable types defined in
Java SE and deserializable from any classloader. But I'm hesitant to
allow just any type to be stored as an execution property (or ContextHint)
because contextual proxies must be able to serialize/deserialize properly,
which means knowing the correct classloader of everything that serializes
along with it.

So I'm curious to learn more about what the "
ContainerSpecificContextObject" is.

Nathan Rauh
____________________________________________
Software Engineer, WebSphere Application Server
IBM Rochester Bldg 002-2 C111
3605 Highway 52N
Rochester, MN 55901-7802



From: Anthony Lai <anthony.lai_at_oracle.com>
To: jsr236-experts_at_concurrency-ee-spec.java.net
Cc: Binod <binod.pg_at_oracle.com>
Date: 01/22/2013 01:07 PM
Subject: [jsr236-experts] New ContextService API proposal from JSR
359 spec lead



Dear Experts,

Binod, the spec lead for JSR 359 - SIP Servlet 2.0, is proposing a new API
in ContextService to pass in application-provided information that can be
retrieved in the thread that executes the task.

Forwarding Binod's suggestion:

<quote>
It is possible for some containers to build contextual object based
on application provided information. For example, a container could
support
thread safe execution of the tasks based on a specific contextual
information.

      <T> T createContextualProxy(T instance, Properties
executionProperties, Class<T> intf, ContextHint<C> hint)
      Object getContextHint(Object contextObject)
      /** Context hint information that contains the container specific
object. **/
      interface ContextHint<C> {
          void setHint(C hint);
          C getHint();
      }

Example code:

 public class MyRunnable implements Runnable {
      public void run() {
          System.out.println("MyRunnable.run with Container Context
available.");
           ContextService ctxService = (ContextService) ctx
 .lookup("java:comp/env/concurrent/ContainerSpecificContextService");
           ContainerSpecificContextObject object =
ctxService.getContextHint(this);
      }
  }
 
  InitialContext ctx = new InitialContext();
  ManagedExecutorService mes = (ManagedExecutorService)
           ctx.lookup("java:comp/env/concurrent/ContainerThreadPool");
 
  ContextService ctxService = (ContextService) ctx
 .lookup("java:comp/env/concurrent/ContainerSpecificContextService");

  MyRunnable myRunnableInstance = ...;
 
  ContextHint<ContainerSpecificContextObject> hint = new
MyContextHint<ContainerSpecificContextObject>(...);
  Runnable rProxy = ctxService.createContextualProxy(myRunnableInstance,
Runnable.class, hint);

  Future f = mes.submit(rProxy);
</unquote>

Any comments are welcome.

Regards
Anthony