Earlier messages in this thread has been removed from the archive per
Fred's request since they contain Fred's personal contact info.
Resending message with Fred's personal info removed.
On 7/26/12 8:13 AM, Frederick W Rowe wrote:
> Although I would still prefer that they be managed via res-refs, we
> agree that they should not be part of Context. If we can't agree on
> using resource refs, I'd be ok with your suggestion to pass as method
> parms to executor service methods directly.
>
> Regards,
>
> Fred Rowe
>
> Senior Software Engineer
> WebSphere Architect
> IBM Software Group
> frowe_at_us.ibm.com
>
>
> *Andrew Evers <andrew.evers_at_gmail.com>*
>
> 06/20/2012 05:50 PM
> Please respond to
> jsr236-experts
>
>
>
> To
> jsr236-experts_at_concurrency-ee-spec.java.net
> cc
>
> Subject
> [jsr236-experts] Re: Fwd: Re: Candidate for Early Draft
>
>
>
>
>
>
>
>
>
> Hi all,
>
> 1) There are two problems that Contexts set out to solve:
> * Capturing vendor specific context to be transported with the task
> being submitted.
> * Passing additional information to Managed*Service
>
> For the first case, static Contexts work fine, there are only so many
> possibilities.
>
> For the second, the properties are much more like JMS properties than
> a JMS Destination, they can indicate to a (perhaps vendor specific)
> service some expectation of quality of service: priority, etc, or
> where the task should (or should not) run. Even two targets and five
> priorities results in 7 possible contexts if you can wrap multiple
> times, 10 if you cannot. The resource-ref approach means that
> operational decisions could require administrative changes.
>
> I'm certainly not attached to them being modeled as Context, I would
> prefer they were passed into the executor service methods directly.
>
> 2)
> a) Triggers need to be serializable. So does the Callable/Runnable if
> it is to run elsewhere.
>
> b) I will need to look through the (old) mailing list archives for all
> the signatures on Trigger, and why Future is in there. It allows the
> Trigger to act based on the task, and probably even the information in
> the context object. I think the main reason it is there is to be able
> to get the result of the last execution, so the caller could just pass
> that. As you point out, most of the rest of the methods are not useful
> or dangerous.
>
> The two trigger methods (getNextRunTime(), skipRun()) should really
> get a LastExecution:
>
> interface LastExecution
> extends IdentifiedFuture
> {
> Object getResult()
> Date getScheduledStart()
> Date getRunStart()
> Date getRunEnd()
> }
>
> interface IdentifiedManagedFuture
> extends IdentifiedTask
> {
> String getManagedIdentifier()
> }
>
> interface IdentifiedTask
> {
> String getTaskIdentifier()
> }
>
> Semantics being:
> * If the Callable/Runnable passed to the the executor service
> implements IdentifiedTask then the executor service should call
> getTaskIdentifier(), store the value, and pass the value when called
> by a Trigger via LastExecution.
> * The executor service should assign a unique identifier to each newly
> submitted task.
>
> This allows the application server administrator or DevOps team to see
> their own identifiers when managing the executor service via the
> application server, and standardized log file correlation.
>
> c) The time would be the time at which the task was scheduled, which
> could be different from when the Trigger was created, or any
> information passed to the Trigger's constructor.
>
> The other three times could do with better descriptions. The other
> three useful times are:
> * the value getNextStartTime() returned (scheduled start) the previous
> time it was called;
> * the last time the task started (run start); and;
> * the last time the task ended (run end).
>
> Of these the task start/end need to be provided. The trigger could
> store the last value it returned, but this makes serialization more
> complex (the trigger would need to be reserialized after a call). I
> would expect the same set of times to be passed both to skipRun() and
> getNextStartTime(), the current signatures strike me as inconsistent,
> I think the LastExecution approach above is more elegant.
>
> Regards,
>
> Andrew.
>
> On Wed, Jun 20, 2012 at 3:54 PM, Anthony Lai <_anthony.lai_at_oracle.com_
> <mailto:anthony.lai_at_oracle.com>> wrote:
> Forwarding to EG mailing list for Fred.
>
> -------- Original Message --------
> *Subject: *
> Re: [jsr236-experts] Candidate for Early Draft
> *Date: *
> Mon, 18 Jun 2012 14:42:16 -0600
> *From: *
> Frederick W Rowe _<frowe_at_us.ibm.com>_ <mailto:frowe_at_us.ibm.com>
> *To: *
> _anthony.lai_at_oracle.com_ <mailto:anthony.lai_at_oracle.com>
>
>
>
>
> Anthony,
>
> I've attached a commented version of the draft spec below.
>
>
> Here are my comments on API docs. In general, remove IBM author
> attributions from all javadocs. In specific:
>
> 1) *Interface javax.enterprise.concurrent.ContextService*
>
> - Update ContextService to use generics:
> <T> T createContextObject(T instance, Class<T> ifc);
> Object createContextObject(Object instance, Class<?>... interfaces);
>
> - update
>
> * All interface method invocations on a proxy instance run in the
> creator's context.
> * Invocation of the hashCode, equals, and toStringmethods declared
> in java.lang.Objecton a proxy instance will not run in the
> creator's context.
>
> to say instead:
>
> * All interface method invocations on a proxy instance run in the
> creator's context with the exception of the hashCode, equals, and
> toStringmethods declared in java.lang.Object
>
>
> - remove the concept of context properties that are specified in the
> application code. Most context properties will be vendor-specific,
> and using a model where applications hard code vendor specific context
> properties will lead to applications that are not portable. Instead,
> any properties that are needed can be handled in the configuration
> that the application server provides for a ContextService. If an
> application requires specific contexts, a ContextService instance
> should be created for it, and referred to via resource-refs deployment
> descriptor elements or annotations. This implies removal of the
> method declarations:_
> __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,
> _Class_
> <http://download.oracle.com/javase/6/docs/api/java/lang/Class.html?is-external=true>[] interfaces,
> _Properties_
> <http://download.oracle.com/javase/6/docs/api/java/util/Properties.html?is-external=true> contextProperties)
> void setProperties(_Object_
> <http://download.oracle.com/javase/6/docs/api/java/lang/Object.html?is-external=true> contextObject,
> _Properties_
> <http://download.oracle.com/javase/6/docs/api/java/util/Properties.html?is-external=true> contextProperties)_
> __Properties_
> <http://download.oracle.com/javase/6/docs/api/java/util/Properties.html?is-external=true> getProperties(_Object_
> <http://download.oracle.com/javase/6/docs/api/java/lang/Object.html?is-external=true> contextObject)
>
> the class javadoc comments:
>
> * Context properties can be stored with the proxy instance. Custom
> property keys must not begin with "ctxsvc.".
> * Context properties are to be used for controlling how various
> contextual information is retreived and applied to the thread.
> Although application components can store arbitrary property keys
> and values, it is not recommended. Java EE product providers may
> impose limits to the size of the keys and values.
> * Context property keys and values must all be of type
> java.lang.String. Use of the putand putAllmethods on the
> java.util.Hashtablesuperclass are discouraged.
>
>
> and the field:
> static _String_
> <http://download.oracle.com/javase/6/docs/api/java/lang/String.html?is-external=true>*_USE_PARENT_TRANSACTION_*
>
> 2) *Interface javax.enterprise.concurrent.Trigger*
>
> - What is the point of lastFuture parameter in Trigger methods, it is
> not used in the examples?
> - if we consider the use of Triggers on a distributed
> ManagedScheduledExecutorService:
> a. Trigger would need to be serializable
> b. Future provided to Trigger.skipRun() would need to have result from
> different server, and future allows for get/cancel, and so forth. Do
> we really want the possibility of someone invoking those in a trigger?
> c. As an example, consider a Payroll that is triggered to run every
> Friday at midnight. If the server went down on Wednesday and then came
> back up, we still want to see the Payroll run automatically on Friday
> at midnight. But are we expected to provide the Future from last
> week's run before the outage?
> - what is the purpose of he baseTime parameter in:
> _Date_
> <http://download.oracle.com/javase/6/docs/api/java/util/Date.html?is-external=true> getNextRunTime(_Future_
> <http://download.oracle.com/javase/6/docs/api/java/util/concurrent/Future.html?is-external=true> lastFuture,
> _Date_
> <http://download.oracle.com/javase/6/docs/api/java/util/Date.html?is-external=true> baseTime,
> _Date_
> <http://download.oracle.com/javase/6/docs/api/java/util/Date.html?is-external=true> lastActualRunTime,
> _Date_
> <http://download.oracle.com/javase/6/docs/api/java/util/Date.html?is-external=true> lastScheduledRunTime,
> _Date_
> <http://download.oracle.com/javase/6/docs/api/java/util/Date.html?is-external=true> lastCompleteTime)
> The description is circular:
> baseTime- the time in which the next fire time should be based.
> Do we mean the time for which the first execution was scheduled? If
> so, we should state that.
>
>
> Regards,
>
> Fred Rowe
>
> Senior Software Engineer
> WebSphere Architect
> IBM Software Group_
> __frowe_at_us.ibm.com_ <mailto:frowe_at_us.ibm.com>_
> ___ <tel:919-678-0504>
> *Anthony Lai **_<anthony.lai_at_oracle.com>_* <mailto:anthony.lai_at_oracle.com>
>
> 06/04/2012 04:20 PM
>
>
> Please respond to
> jsr236-experts
>
>
>
> To
> _jsr236-experts_at_concurrency-ee-spec.java.net_
> <mailto:jsr236-experts_at_concurrency-ee-spec.java.net>
> cc
>
> Subject
> [jsr236-experts] Candidate for Early Draft
>
>
>
>
>
>
>
>
>
>
>
> Dear experts,
>
> I have created a draft based on the early draft that we have from
> April 2006 with the following changes:
>
> * Updated Copyrights and Licenses
> * Updated package name from javax.util.concurrent to
> javax.enterprise.concurrent
> * Fixed typos
> * Updated references to Java EE specifications
> * Added references to resource injection in sections 3.1.1, 3.2.1,
> 3.3.1, and 3.4.1 and updated code examples
> * Added Thread Use configuration attribute to ManagedExecutorService
> configuration example in section 3.1.4.1
>
> The document can be found at_
> __http://java.net/projects/concurrency-ee-spec/downloads/download/EE%20Concurrency%20Utilities.pdf_
>
> A version with marks showing what have been updated can be found at_
> __http://java.net/projects/concurrency-ee-spec/downloads/download/EE%20Concurrency%20Utilities%20-%20delta.pdf_
>
> We are hoping to publish an the Early Draft to the JCP website soon
> for the Early Draft Review as specified in the JCP process.
>
> Please take a look at this latest draft and send email to this list if
> there any issues, concerns, or comments.
>
> Thanks
> Anthony
>
>