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