Original message has been removed from archive per Fred's request.
Resending message to the list with Fred's personal info removed for the
archive.
On 6/22/12 3:46 PM, Anthony Lai wrote:
> Hi all,
>
> 1) Contexts
>
> I can see the argument either way on whether to keep the properties.
> If anyone has something to add please chime in.
>
> The idea of passing in Context directly to Managed*Service is
> interesting. I have looked into Connectors WorkManager interface in
> javax.resource.spi.work package briefly. Their APIs support passing in
> optional WorkContext through the Work instance. Thus Connectors could
> programmatically varies WorkContext in each work using the same
> WorkManager.
>
> 2) Trigger
> a) I will add the requirement to the spec. About Callable/Runnable, I
> believe the spec already mentioned that Callable should be
> serializable if it needs to be run in distributable Managed*Service.
> b/c) Please let us know if you found from old mailing list archives
> why Future is in the method signature. Thanks.
>
> With your suggestion, would the Trigger methods become:
>
> Date getNextRunTime(LastExecution lastExecutionInfo, Date
> taskScheduledTime)
>
> boolean skipRun(LastExeuction lastExecutionInfo, Date scheduledRunTime)
>
> What about information from lastFuture including future.isCancelled()
> and future.isDone()? Should these be included in the LastExecution
> interface too?
>
> Also, what would the Id from getManagedIdentifier() be used for?
>
> There is already an interface Identifiable that could be used to
> identify the task. Could that be used here?
>
> Regards
> Anthony
>
>
> On 6/20/12 2:50 PM, Andrew Evers wrote:
>> 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
>>
>>