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