Thanks for the feedback.
If nobody objects, I can start working on adding default instances
support for MES, MSES, ContextService, and MTF.
Agree that Naming, classloader, and security are good candidates as
standard context. We can use these as the set of default set of contexts
to be propagated.
To clarify "Container Context", how about rewriting this paragraph in
section 2.3
"The contexts to be propagated are governed by the container but
typically include naming context, class loader and security information."
with
"The contexts to be propagated includes naming context, class loader,
and security information. Container must support propagation of these
context types. In addition, containers can choose to support propagation
of other types of context."
Regarding the issue of requiring JSR 236 objects to be bound to the
java:comp/env/concurrent subcontext. I checked with Linda, the spec lead
for Java EE 7, and she says that is not consistent with the other
resource types. So I suggest that we should keep it as a recommendation.
About defining resources via annotations. Looks like we don't have an
agreement yet. Let's see if we get more feedback from other experts.
Regards
Anthony
On 11/28/12 7:36 AM, Nathan Rauh wrote:
> I really like the idea of default instances that would be consistent
> with other resource types in EE 7 as Anthony pointed out. For the
> majority of apps, this would provide a simple, zero-configuration way
> to use
> ManagedExecutorService/ScheduledExecutorService/ContextService/ThreadFactory
> that is easily and straightforwardly overridable by the deployer.
> Writing this up would just involve copying from EE 7 section 5.20 or
> 5.21and replacing with the JSR 236 resource types, but on top of that
> I would recommend that we standardize a minimum set of contexts that
> must be propagated by the default instances, provided the container
> supports those contexts. Naming/classloader/security as mentioned
> previously would make sense.
>
> I would prefer that we not take the approach of having annotations
> that define new instances, which in the case of
> @ManagedExecutorService/_at_ManagedScheduledExecutorService results in a
> proliferation of separate thread pools across applications. I would
> prefer not to see applications managing their own thread pools, but in
> the cases where it truly is necessary, the ability to use
> ThreadFactory (and ContextService) with the Java SE executors already
> allows for that.
>
> Nathan Rauh
> ____________________________________________
> Software Engineer, WebSphere Application Server
> IBM Rochester Bldg 002-2 C111
> 3605 Highway 52N
> Rochester, MN 55901-7802
>
>
>
> From: Frederick W Rowe/Raleigh/IBM_at_IBMUS
> To: jsr236-experts_at_concurrency-ee-spec.java.net
> Date: 11/28/2012 07:14 AM
> Subject: [jsr236-experts] Re: Feedback
> ------------------------------------------------------------------------
>
>
>
> All,
>
> Wrt to Adam's comments and Anthony's responses/questions.
>
> 3. The terminology of the original comment is somewhat confusing:
> "start with the injection of plain Executor services managed by the
> container." Isn't a plain Executor service managed by the container
> simply a ManagedExecutorService? Is the proposal that the scope of
> the JSR be reduced to simply supporting MES? I think MES by itself is
> useful without ContextService ONLY if there is a standard set of
> contexts propagated by default. This goes back to my proposal earlier
> this year to make MES required and the other three APIs optional. The
> problem with the default propagation of contexts is that we never got
> enough feedback on the discussion started by Nathan on an earlier
> thread of what that set of contexts was.
>
> 4. The comment: "Often mentioned "Container Context" is not clearly
> defined." The intent of section 2.3, Container Thread Context, is to
> define that, please make specific change proposals for that section to
> address any shortcomings. As mentioned above however, there is not
> yet a general consensus of a finite set of contexts, so it is possible
> that simply listing all of the contexts currently known to the EG is
> the best we can do.
>
> 5. The comment: "We should reduce optional things. E.g. jndi names
> etc.", is misleading, JNDI names are mandatory:*
> JNDI name*: The arbitrary, but required, name to identify the service
> instance. The deployer uses this
> value to map the service to the component’s resource environment
> reference.
> What is not mandatory is the namespace into which they are bound. If
> the proposal is to require the use of a specific namespace subcontext
> (like java:comp/env/concurrent), I'm ok with that.
> I think that defining annotations for the managed objects is a good
> idea and fairly easy to do. Does someone want to make a proposal of
> what those would look like?
>
> Separate from that discussion, please correct the following
> inconsistency in the document:*/
> 2.3.1.1 Optional Contextual Invocation Points/*
> ...
> Configuration option Callback-Context is available in
> ManagedExecutorService and
> ...
>
> should state:
> ...
> Configuration option *Contextual-Callback*is available in
> ManagedExecutorService and
> ...
>
> Regards,
>
> Fred Rowe
>
> WebSphere Architect
> Senior Software Engineer
> IBM Software Group
> frowe_at_us.ibm.com
>
> *Anthony Lai <anthony.lai_at_oracle.com>*
>
> 11/27/2012 04:48 PM
> Please respond to
> jsr236-experts
>
>
> To
> jsr236-experts_at_concurrency-ee-spec.java.net, Adam Bien
> <abien_at_adam-bien.com>
> cc
>
> Subject
> [jsr236-experts] Re: Feedback
>
>
>
>
>
>
>
>
>
>
>
> Hi Adam,
>
> 1. DI of resources
> Thanks for pointing this out. I have fixed the incorrect usages of DI
> in the Early Draft.
>
> 2. Injection without XML confiuguration
> Which instance should be injected without any configuration? Should
> the container inject some default instance similar to the "default
> Data Source" and "default JMS Connection" mechanism as described in
> sections 5.20 and 5.21 in the Java EE 7 spec?
>
> 3. Reduce the scope and start with the injection of plain Executor
> services
> What do other experts feel about reducing the scope?
>
> 4. "Container Context" not clearly defined
> The spec provides examples of what are the possible container context
> that could be propagated, such as naming context, class loader,
> security. It is up to the container to decide what context to be
> propagated. I guess this falls into the same issue as your next point
> about reducing optional things. Perhaps we should identify the common
> context and standardize them. I think JNDI and security would be the
> candidates.
>
> I would think transaction is typically not one of the context to be
> propagated.
>
> 5. Reduce optional things
> You suggested that we should require, instead of just recommend, that
> resources to be bound in the java:comp/env/concurrent subcontext. I
> saw a few examples in the Java EE spec that tends to provide
> recommendation instead of requirement when it talks about binding of
> particular types of objects into specific subcontext. Should we follow
> that convention? Are there any problems with making it an requirement
> to bind JSR 236 objects into java:comp/env/concurrent?
>
> Your other suggestion is to remove all examples of configuration
> attributes, and select a few to become standard configuration
> attributes. I think we should do this. Any suggestions on which
> attributes we should consider to be standardize?
>
> Furthermore, suppose we have defined a set of required attributes and
> their possible values, would it be useful to provide annotations for
> defining JSR 236 objects?
>
> There are annotations in the Java EE 7 spec for defining various types
> of resources. Taking an example from section 5.19.6 in the Java EE
> spec, a mail session resource can be defined on a container-managed
> class by using this annotation:
>
> @MailSessionDefinition( name="java:app/mail/MySession",
> host="somewhere.myco.com", from=_"some.body_at_myco.com"_
> <mailto:some.body_at_myco.com>)
>
> For example, a ManagedExecutorService could be defined by something like
> @ManagedExecutorService (name="java:comp/env/concurrent/executor1",
> context="all", threads="3")
>
> Comments are welcome.
>
> Regards
> Anthony
>
> On 10/16/12 12:46 PM, Adam Bien wrote:
> HI *,
>
> I read the proposal and probably found some problems / inconsistencies
> (or completely misunderstood that :-)).
>
> I incorporated the comments into the PDF--see attachment.
>
> Summary of my comments:
> 1. DI of resources into manually created tasks won't work, or has to
> be performed by the pools. We should clarify that.
> 2. We should rely more on Convention over Configuration. It means:
> injection should work without any XML configuration.
> 3. I would reduce the scope and start with the injection of plain
> Executor services managed by the container. It would already solve
> about 80% of challenges from my projects.
> 4. Often mentioned "Container Context" is not clearly defined. I guess
> TX are not covered by the definition. Otherwise a in EJB initiated TX
> could be propagated into an asynchronous task...
> 5. We should reduce optional things. E.g. jndi names etc. should be
> mandatory--otherwise the suggestions are worthless. I would reduce the
> scope of the whole spec to mandatory services, and discuss the
> optional things later.
>
> Please see my comments in the PDF,
>
> thanks!
>
> adam
>
>
>