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")
For example, a ManagedExecutorService could be defined by something like
@ManagedExecutorService (name="java:comp/env/concurrent/executor1", context="all", threads="3")
JavaEE_Platform_Spec.book
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
>