Forwarding to the EG mailing list for Nathan
-------- Original Message --------
Subject: Re: [jsr236-spec users] [jsr236-experts] Early Draft for
planned submission Nov 9
Date: Mon, 5 Nov 2012 15:33:33 -0600
From: Nathan Rauh <naterauh_at_us.ibm.com>
To: jsr236-experts_at_concurrency-ee-spec.java.net, Anthony Lai
<anthony.lai_at_oracle.com>
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