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>
> To: 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
>