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

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

From: Anthony Lai <anthony.lai_at_oracle.com>
Date: Mon, 19 Nov 2012 10:15:11 -0800

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:
> 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_at_IBMUS
> To: jsr236-experts_at_concurrency-ee-spec.java.net
> 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
> frowe_at_us.ibm.com
> 919-678-0504 (Home Office)
> 919-608-1159 (Cell)
>
> *Anthony Lai <anthony.lai_at_oracle.com>*
>
> 11/16/2012 03:45 PM
> Please respond to
> jsr236-experts
>
>
> To
> jsr236-experts_at_concurrency-ee-spec.java.net
> 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 _<anthony.lai_at_oracle.com>_
> <mailto:anthony.lai_at_oracle.com>
> To: _jsr236-experts_at_concurrency-ee-spec.java.net_
> <mailto:jsr236-experts_at_concurrency-ee-spec.java.net>
> 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_
> <http://download.oracle.com/javase/6/docs/api/java/util/Properties.html?is-external=true>contextProperties,
> _Class_
> <http://download.oracle.com/javase/6/docs/api/java/lang/Class.html?is-external=true><T>
> intf)_
>
> __Object_
> <http://download.oracle.com/javase/6/docs/api/java/lang/Object.html?is-external=true>createContextObject(_Object_
> <http://download.oracle.com/javase/6/docs/api/java/lang/Object.html?is-external=true>instance,
> _Properties_
> <http://download.oracle.com/javase/6/docs/api/java/util/Properties.html?is-external=true>contextProperties,
> _Class_
> <http://download.oracle.com/javase/6/docs/api/java/lang/Class.html?is-external=true><?>...
> interfaces)
>
> with
>
> <T> T createContextObject(T instance,
> ContextHints contextHints,
> _Class_
> <http://download.oracle.com/javase/6/docs/api/java/lang/Class.html?is-external=true><T>
> intf)_
>
> __Object_
> <http://download.oracle.com/javase/6/docs/api/java/lang/Object.html?is-external=true>createContextObject(_Object_
> <http://download.oracle.com/javase/6/docs/api/java/lang/Object.html?is-external=true>instance,
> ContextHints contextHints,
> _Class_
> <http://download.oracle.com/javase/6/docs/api/java/lang/Class.html?is-external=true><?>...
> 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 _<anthony.lai_at_oracle.com>_
> <mailto:anthony.lai_at_oracle.com>
> To: _jsr236-experts_at_concurrency-ee-spec.java.net_
> <mailto:jsr236-experts_at_concurrency-ee-spec.java.net>
> 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_
> <http://concurrency-ee-spec.java.net/javadoc/javax/enterprise/concurrent/ContextService.html#createContextObject%28T,%20java.util.Properties,%20java.lang.Class%29>.
> 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_ <http://java.net/jira/browse/CONCURRENCY_EE_SPEC-10>
>
> 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
> toStringmethods 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 _<anthony.lai_at_oracle.com>_
> <mailto:anthony.lai_at_oracle.com>
> To: _jsr236-experts_at_concurrency-ee-spec.java.net_
> <mailto:jsr236-experts_at_concurrency-ee-spec.java.net>
> 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