Resending for Fred with the personal contact info taken out.
-------- Original Message --------
Subject: [jsr236-experts] Re: issue 10: ContextService properties
Date: Mon, 19 Nov 2012 09:48:56 -0500
From: Frederick W Rowe <frowe_at_us.ibm.com>
Reply-To: jsr236-experts_at_concurrency-ee-spec.java.net
To: jsr236-experts_at_concurrency-ee-spec.java.net
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
*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