Skip to main content

[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties

  • From: Anthony Lai < >
  • To:
  • Subject: [jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties
  • Date: Mon, 19 Nov 2012 10:15:11 -0800
  • List-id: <jsr236-experts.concurrency-ee-spec.java.net>

Hi Nathan,

Agree. I will update the javadoc to says

Returns:
A copy of the current context object properties

Regards
Anthony

On 11/19/12 8:11 AM, Nathan Rauh wrote:
" type="cite">Should the documentation for  getContextProperties()  say that it returns a copy of the current properties rather than "the current properties on the context proxy instance" ?

Otherwise the lack of clarify will allow for some implementations to permit the following,

myContextObject = contextService.createContextObject(myObject, new Properties(), myInterface);

props = contextService.getContextProperties(myContextualObject);
props.setProperty(USE_PARENT_TRANSACTION, "true");
myContextualObject.doSomethingThatOughtToRunInParentTran();

props = contextService.getContextProperties(myContextualObject);
props.setProperty(USE_PARENT_TRANSACTION, "false");
myContextualObject.doSomethingThatShouldNotRunInParentTran();

and applications could end up with unportable behavior.


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




From:        Frederick W Rowe/Raleigh/IBM@IBMUS
To:         ">
Date:        11/19/2012 08:51 AM
Subject:        [jsr236-experts] Re: issue 10: ContextService properties




I agree to getting rid of the setContextProperties() method because of the complexities it adds.

Regards,

Fred Rowe

Senior Software Engineer
WebSphere Architect
IBM Software Group
">
919-678-0504 (Home Office)
919-608-1159 (Cell)


Anthony Lai ">< >

11/16/2012 03:45 PM

Please respond to
jsr236-experts

To
">
cc

Subject
[jsr236-experts] Re: issue 10: ContextService properties









Hi Nathan,

Fair enough. I will close the issue unless other experts suggest otherwise.

Regarding 2 different mechanisms for configuring context properties. I agree that the setContextProperties() approach is more flexible but more complex. The user of the context object cannot rely on the property value and as a result it is better to always set the property explicitly before invoking methods on the context object to make sure. So if we want to keep things simply I would prefer getting rid of the setContextProperties method. Just my 2 cents.

Regards
Anthony

On 11/16/12 7:26 AM, Nathan Rauh wrote:

Anthony,


I was just discussing this with Fred, who pointed out (and managed to convince me) that since there doesn't seem to be much interest in standardizing any application-defined context properties other then useParentTransaction, that it's probably fine to just use java.util.Properties as currently written, so we are withdrawing the issue
CONCURRENCY_EE_SPEC-10 that we raised for this.

You did bring up an interesting point about the ContextService API currently having two different mechanisms for configuring context properties.

contextService.createContextObject(instance, contextProperties, interface)

vs

contextService.setContextProperties(contextualObject, contextProperties)


I'd prefer choosing one mechanism or the other for the API and not having both of them.

The latter is more flexible (as it allows for reuse of a contextualized object with different properties) but also more complex in that context properties could change while contextual operations are running (I assume the expectation here is that the context properties as of the start of the contextual operation would continue to be honored for the duration of that operation, and subsequent contextual operations would pick up the updated properties).



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




From:        
Anthony Lai ">< >
To:        
">
Date:        
11/15/2012 05:48 PM
Subject:        
[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties




Hi Nathan,

So we are going to replace these methods in ContextService


<T> T createContextObject(T instance,
                     
Properties contextProperties,
                     
Class<T> intf)

Object createContextObject(Object instance,
                       
Properties contextProperties,
                       
Class<?>... interfaces)

with

<T> T createContextObject(T instance,
                      ContextHints contextHints,
                     
Class<T> intf)

Object createContextObject(Object instance,
                       ContextHints contextHints,
                       
Class<?>... interfaces)



With properties, to specify hints after the context object has been created, one would do:

      Properties ctxProps = ctxSvc.getProperties(msgProcessor);
      ctxProps.setProperty(ContextService.USE_PARENT_TRANSACTION, "true");
      ctxSvc.setProperties(msgProcessor, ctxProps);


Now that we are replacing properties with ContextHint, should we replace the setProperty and getProperties method with possibly a setContextHint method? It would override the value of the ContextHints used when creating the ContextObject. For example:


     ctxSvv.setContextHints(msgProcessor, contextHints);



Regarding compatibility issues, I found this page about backward compatibility requirements for Java EE specs:
http://java.net/projects/javaee-spec/pages/CompatibilityRequirements
I think by making the ContextHints a class, adding new methods in future release should not break source or binary compatibility.

I would start making these changes if this looks fine to everyone.

Regards
Anthony


On 11/14/12 3:22 PM, Nathan Rauh wrote:

Anthony,


Yes, that is right along the lines of what I was suggesting.

However, in reading through your example, which provides a good illustration of how this works, I noticed an error with what I proposed, which is that I assumed the object being contextualized is owned by the invoker of contextService.createContextObject, such that there is the opportunity to update the implementation of the object being contextualized to provide the context hints interfaces (or annotations).  What I wasn't thinking about before is that the application sometimes owns the implementation of the object it wants to contextualize, and other times not.  The context Properties solution addressed that scenario because the context properties were a separate and independent parameter to createContextObject.   Additionally, in seeing the examples, I expect there will be version to version compatibility issues with updates that are made to future versions of intefaces like TransactionContextHints.  For example, if a new interface method were later added to TransactionContextHints, it would break applications that implemented the older version.

In order to maintain flexibility in both of these areas, it is probably best to instead have a single ContextHints class which would be used as follows,


contextHints = new ContextHints();

contextHints.setUseParentTransaction(true);

msgProcessor = contextService.createContextObject(contextHints, new MessageProcessor(), ProcessMessage.class);


There would be a corresponding getter method for the context service to invoke,

boolean contextHints.getUseParentTransaction();   // I'm not good at naming things, this could maybe use some improvement


ContextHints ought to be serializable so that the result of createContextObject can be serialized.


And to maintain compatibility with future versions, anything that isn't explicitly set should be defaulted.


This could also serve as a very straightforward extension point for vendors (although I wouldn't write this part into the spec).  For example,


vendorContextHints = new VendorAContextHints();    // where VendorAContextHints extends ContextHints

vendorContextHints.setVendorASecurityTokenExpiration(15000);

vendorContextHints.setUseParentTransaction(true);

msgProcessor = contextService.createContextObject(vendorContextHints, new MessageProcessor(), ProcessMessage.class);



This is essentially just asking to switch the contextProperties from a key/value java.util.Properties to a more specific and well-defined type with accessor methods for each property.

Although I'm starting to see some of the widsom of the existing java.util.Properties approach because it makes the serialization and cross version compatibility easier by just relying on java.util.Properties for that part.



Anthony/Fred,

I'm not sure if this will go through to the list - if not please forward it.



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




From:        
Anthony Lai ">< >
To:        
">
Date:        
11/13/2012 05:43 PM
Subject:        
[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties




Hi Nathan,

Thanks for the suggestion.

Let's walk through the example in the
ContextService javadoc. The example currently contains the following:

   public class MyServlet ... {
      ...

      // Get the ContextService that only propagates
      // security context.
      ContextService ctxSvc = (ContextService)
          ctx.lookup("java:comp/env/SecurityContext");

      // Set any custom context data.
      Properties ctxProps = new Properties();
      ctxProps.setProperty("vendor_a.security.tokenexpiration", "15000");

      ProcessMessage msgProcessor =
          ctxSvc.createContextObject(new MessageProcessor(), ctxProps,
          ProcessMessage.class);
      ...

  public class MyMDB ... {
      ...
      ContextService ctxSvc = (ContextService)
          ctx.lookup("java:comp/env/SecurityContext");

       Properties ctxProps = ctxSvc.getProperties(msgProcessor);
      ctxProps.setProperty(ContextService.USE_PARENT_TRANSACTION, "true");
      ctxSvc.setProperties(msgProcessor, ctxProps);

       // Process the message in the specified context.
      msgProcessor.processMessage(msg);
      ...



Suppose we remove properties from ContextService and create a new interface with the useParentTransaction() method. Let's call it TransactionContextHint for now.

The property "vendor_a.security.tokenexpiration" is vendor specific and is beyond the scope of the spec, so it would be taken out of this example.

To specify that the processMessage() method should be run within the transaction of the MDB, instead of setting the USE_PARENT_TRANSACTION property, the MessageProcessor would implement our new TransactionHints interface:

 
public class MessageProcessor implements ProcessMessage, Serializable, TransactionContextHints {
    public void processMessage(Message msg) {
        // Process the message with the application container
        // context that sent the message.
        ...
    public boolean useParentTransaction() {
        return true;
    }
    ...



Is this inline with what you are suggesting?

Currently we only have one such property, useParentTransaction(). Should we have more in the future, say isLongRunning() as in your example, do you prefer they go to a different interface or do we use one interface for all these standard properties?

What about using new annotation type? We could modify MessageProcessor class in the example to something like this:


 public class MessageProcessor implements ProcessMessage, Serializable {
    @UseParentTransaction
    public void processMessage(Message msg) {
        // Process the message with the application container
        // context that sent the message.
        ...


This tells the container that the processMessage() method in the proxied object created by ContextService should be run under the parent transaction. Is this feasible? What do you think?

Regards
Anthony

On 11/5/12 1:33 PM, Nathan Rauh wrote:

Anthony,


I work on Fred's team, and was reviewing the draft, and noticed one of the issues we had raised was still open.

CONCURRENCY_EE_SPEC-10: Remove the concept of context properties from ContextService

First - I agree this open issue (or any of the others) should not hold up progress of the JSR.


I would, if possible, like to help with a resolution for it.


I agree there is certainly value in an application being able to identify certain details about its intended usage of, or requirements for, a contextual operation.   USE_PARENT_TRANSACTION from the existing JavaDoc is a perfect example - only the application would know whether it's valid from a business logic standpoint to run in a new or existing transaction.  The administrator shouldn't need to be aware of these sort of details.

That said, we don't want to encourage the proliferation of non-portable code in applications.  We shouldn't need to standardize any particular mechanism for vendor-specific information to be supplied in application code, as vendors in any case already have the freedom to come up with their own extensions using any mechanisms they want (including but not limited to String name/value pairs with a vendor API like what's currently in the JavaDoc).

If we can agree that it's not necessary to enforce a particular mechanism for vendor-specific extensions, and take that out of the picture, then we have an opportunity to make what we do standardize for portable apps more straightforward and user-friendly.

For example, a simple true/false interface method like,

  boolean useParentTransaction();

Or, as another example,  (I'm not suggesting we need to add this - it's just an example)

  boolean isLongRunning();

These could go on Identifiable or on another new class/interface that we create for the purpose of identifying application-provided task details.

Such an interface could be used just like Identifiable and submitted to ManagedExecutorService or ManagedScheduledExecutorService as well as ContextService.

Whatever the mechanism we choose, it will be most beneficial to our users if we can agree on and standardize as much as possible of what information we know or expect they'll want/need to provide. Otherwise this will be the cause of lots of non-portable apps.


Hopefully this contributes towards a resolution rather than confusing things further.


I also noticed the following minor issue on the ContextService JavaDoc,

"All interface method invocations on a proxy instance run in the creator's context with the exception of
hashCode, equals, and toString methods declared in java.lang.Object "
which is good because we wouldn't want those methods running with context.  Specifically mentioning only these three methods implies that other java.lang.Object methods (wait, notify, getClass, finalize, ...) should run with context, which I assume is not what we really want.  Would it make sense to update as follows?

"All interface method invocations on a proxy instance run in the creator's context with the exception of
hashCode, equals, and toString  and all other methods declared in java.lang.Object "

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




From:        
Anthony Lai ">< >
To:        
">
Date:        
11/02/2012 03:46 PM
Subject:        
[jsr236-spec users] [jsr236-experts] Early Draft for planned submission Nov 9




Dear experts,

I have posted an updated version of the early draft with only minor changes from the previous version:
  • Fixed usages of dependency injections in code examples throughout the document.
  • Clarified “optional” in optional contextual invocation points in section 2.3.1.1.
  • Added section for open issues.
  • Reduced levels of sub-sections in various Usage Example sections.
The document can be found at
http://java.net/projects/concurrency-ee-spec/downloads/download/EE%20Concurrency%20Utilities-Nov2.pdf

A version showing changes from the previous version can be found at

http://java.net/projects/concurrency-ee-spec/downloads/download/EE%20Concurrency%20Utilities-nov2-delta.pdf

No API changes were made this time. The javadoc zip file can be found at
http://java.net/projects/concurrency-ee-spec/downloads/download/javax.enterprise.concurrent-api-1.0-SNAPSHOT-javadoc.jar

We are planning to use this version of the document along with the javadoc zip file for submission to the JCP PMO office for Early Draft Review at the end of next week so that we can get feedback from the public and officially get the JSR out of inactive state. Please review the document so I could make any corrections before forwarding the draft to the PMO office.

We will continue to work on the spec to address any outstanding or new issues.

Regards
Anthony




[jsr236-spec users] [jsr236-experts] Early Draft for planned submission Nov 9

Anthony Lai 11/02/2012

[jsr236-spec users] [jsr236-experts] Re: Early Draft for planned submission Nov 9

Anthony Lai 11/09/2012

Message not available

[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties

Anthony Lai 11/13/2012

[jsr236-spec users] [jsr236-experts] Re: Re: issue 10: ContextService properties

Nathan Rauh 11/14/2012

[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties

Anthony Lai 11/15/2012

[jsr236-spec users] [jsr236-experts] Re: Re: issue 10: ContextService properties

Nathan Rauh 11/16/2012

[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties

Anthony Lai 11/16/2012

Message not available

[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties

Nathan Rauh 11/19/2012

[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties

Anthony Lai 11/19/2012

Message not available

[jsr236-spec users] [jsr236-experts] Re: issue 10: ContextService properties

Anthony Lai 11/21/2012
 
 
Close
loading
Please Confirm
Close