We should say that if this annotation is used on a class annotated @Alternative, then it is only activated if the alternative is enabled.

How will this play together with the new @Optional you proposed for the MR?

As far as I've seen in the EJB-3.0 spec and from javax.persistence, the container is not explicitly obligated to throw an Exception if the right EntityManagerFactory or an EntityManager cannot be found.

In Addition to this and to @javax.faces.bean.ManagedBean it seems there is another @javax.annotation.ManagedBean class that handles lifecycle callbacks, interceptors and @Resource injection. Do you have any idea for integrating this one? br, Sven 2009/12/31, Gavin King <gavin.king(a)gmail.com&gt;: > Here's something else that has come up: > > http://smokeandice.blogspot.com/2009/12/datasourcedefinition-hidden-gem-f... > > Basically, the common annotations spec introduced the > @DataSourceDefinition annotation without telling anybody about it, so > as usual we have new bits of the platform which don't work properly > together. Grrr. > > We should say that if this annotation is used on a class annotated > @Alternative, then it is only activated if the alternative is enabled. > > On Tue, Dec 29, 2009 at 4:44 PM, Gavin King <gavin.king(a)gmail.com&gt; wrote: >> Folks, I want to start work on the first CDI maintenance release, and >> push it out fairly quickly. We've already discussed a couple of things >> that we wanted in CDI 1.0, but had to delay to the maintenance >> release: >> >> * Bean declaration at constructor level >> * Abstract producer methods >> * Injection into static members >> >> I want to discuss these things in separate threads. >> >> I also have a list of enhancements to the portable extension SPI, >> which was the least-mature part of the spec, and I would like to >> discuss with you guys whether some of those enhancements could/should >> be rolled into the maintenance release. >> >> For now, I just want to update the spec with a list of clarifications >> that have cropped up. Please read over these items and speak up if you >> have an opinion on any of them! >> >> ++ Methods of abstract decorators >> >> The CDI 1.0 spec does not define what happens with abstract methods of >> an abstract decorator class. This was an oversight. We should probably >> say: >> >>    * If a decorator class declares an abstract method that is not >> declared by one of the decorated types, a definition error results >>    * All abstract methods have a container-generated implementation >> that simply delegates the method call to the delegate object >> >> With this definition, I don't think we need any special-casing for >> abstract methods annotated @Inject, @PostConstruct, etc. >> >> ++  Clarify that scope types should not have members >> >> The spec should mention that @ScopeType annotations should not have >> annotation members. Perhaps this should be a definition error. >> javax.inject.Scope already mentions this. >> >> ++ Clarify that parameters of producer and disposer methods are >> injection points of the producer method bean >> >> We say that "....parameters are injection points." We should be >> clearer and say "....parameters are injection points of the producer >> method bean." >> >> ++ Clarify that not all classes in a bean archive are bean classes >> >> We should be clearer and say that you can put non-bean classes (e.g. >> MDBs) in a bean archive. >> >> ++ Clarify that there can be multiple AnnotatedType instances per Java >> class >> >> This is not 100% clear in the spec. >> >> ++ Clarify that interceptors/decorators don't apply to producers in >> resolution rules >> >> We say this in the preamble, but we should also mention it in the >> resolution rules. >> >> ++ In lifecycle chapter, clarify creation of interceptors/decorators >> >> Not sure precisely what we need to say, but the note in 11.2 is not >> sufficient, I think. >> >> ++ Producers and beans that are under construction >> >> I think we need the spec to say something about cases where an >> injection point of a bean resolves to a producer method of the same >> bean. The implementation should detect that this is a definition >> error. It shouldn't try to call a producer method on a >> non-fully-initialized bean. >> >> >> -- >> Gavin King >> gavin.king(a)gmail.com >> http://in.relation.to/Bloggers/Gavin >> http://hibernate.org >> http://seamframework.org >> > > > > -- > Gavin King > gavin.king(a)gmail.com > http://in.relation.to/Bloggers/Gavin > http://hibernate.org > http://seamframework.org > > _______________________________________________ > weld-dev mailing list > weld-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev >

++ Clarify that scope types should not have members The spec should mention that @ScopeType annotations should not have annotation members. Perhaps this should be a definition error. javax.inject.Scope already mentions this.

++ Clarify that interceptors/decorators don't apply to producers in resolution rules

++ Producers and beans that are under construction I think we need the spec to say something about cases where an injection point of a bean resolves to a producer method of the same bean. The implementation should detect that this is a definition error. It shouldn't try to call a producer method on a non-fully-initialized bean.

-- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org

> ++  Clarify that scope types should not have members > > The spec should mention that @ScopeType annotations should not have > annotation members. Perhaps this should be a definition error. > javax.inject.Scope already mentions this. I'm sure you meant @NormalScope.

Can I ask what the motivation is for preventing annotation members on scope annotations?  I could imagine some custom scopes needing some extra metadata, and the scope annotation seems like a handy place to put it.

> ++ Clarify that interceptors/decorators don't apply to producers in > resolution rules > I don't understand.  7.2 seems to explicitly state that interceptors/decorators *do* apply to producer methods.  Can you clarify?

So, I think it'd be very helpful to have a section devoted to cyclic dependencies.  Some kind of cyclic dependencies are ok while others are not, and I think we can enumerate these.

Is this maintenance release an appropriate time to address this question? (I haven't yet checked how Weld handles this)

Also, I'm a little surprised your list didn't contain a ConversationManager API.  Is this too big of a thing for a maintenance release?  It seems pretty important to me.

So, if someone needs metadata on a bean for a custom context, they'll have no choice but to require that an annotation be available from bean.getBeanClass() or bean.getStereotypes().  I think in practice people can live with this.

But when they do, this restriction would require them to use 2 annotations everywhere.  I predict people will complain.  If we have to live with that, then we have to.

But you didn't really answer the question.  Why go out of your way to prevent annotation members?

> Propose some language :-) Ok, will work on this.  Sounds like you're implying that this MR is an appropriate time for this question (provided the language works out).

From: Gavin King <gavin.king(a)gmail.com&gt; Subject: Re: [weld-dev] Maintenance release To: "Java Community Process JSR #299 Expert List" <JSR-299-EG(a)jcp.org&gt;, "Weld-Dev" <weld-dev(a)lists.jboss.org&gt; Date: Thursday, January 7, 2010, 9:29 PM Here's another area of clarification: The spec is underdefined in section 7.3.6. Various clarifications are needed, including that:     * the instance of EntityManager associated with a resource declaration is the same instance that would be injected using @PersistenceContext, i.e. the JPA transaction-scoped container-managed persistence context reference,     * stateful EJB references are not automatically destroyed by the container (the app must call the @Remove method explicitly), and     * EJB and web service references are truly @Dependent scoped (instance per injection) We should remove this sentence: "When the destroy() method is called, the container discards this internal reference and performs any cleanup required of state associated with the client or transaction." On Tue, Dec 29, 2009 at 4:44 PM, Gavin King <gavin.king(a)gmail.com&gt; wrote: > Folks, I want to start work on the first CDI maintenance release, and > push it out fairly quickly. We've already discussed a couple of things > that we wanted in CDI 1.0, but had to delay to the maintenance > release: -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev

From: Pete Muir <pmuir(a)redhat.com&gt; Subject: Re: [weld-dev] Maintenance release To: "Mark Struberg" <struberg(a)yahoo.de&gt; Cc: "Java Community Process JSR #299 Expert List" <JSR-299-EG(a)jcp.org&gt;, "Weld-Dev" <weld-dev(a)lists.jboss.org&gt;, "Gavin King" <gavin.king(a)gmail.com&gt; Date: Monday, January 11, 2010, 3:23 PM On 10 Jan 2010, at 21:36, Mark Struberg wrote: > Hi Gavin! > > A few random observations from a non-native english speaker, so beg your pardon if I got something wrong ;) > > Clarifying the 'Context' lifespan: > > I think it is currently not clear what a Context instance represents. > > While the wording in the default scope lifecycle section (6.7) suggests that there are n (multiple) Context objects for a specific Scope annotation [1] (e.g. one SessionContext instance for each session), the system eventing section (11.5.2) [2] only allows adding a single Context for a Scope annotation (kind of a Context-Facade?). > > [1] 6.7.2 > The session context is shared between all servlet requests that occur _in_the_same_HTTP_session (->another session gets another session context?). The session context is destroyed when the HTTPSession times out, after all HttpSessionListeners have been called, and at the very end of any request in which invalidate() was called, after all filters and ServletRequestListeners have been called (->again backs the n-contexts theory). I think you are inserting the word "instance" into these sentences in your head when you read them - if you re read 6.7.2 "The session context is provided by a built-in context object" you can see the spec does differentiate between the concept of the "session context" (multiple contexts per application instance) and the "context object for the session" (one instance per application instance). Perhaps there is a way to clean up the language to make it clearer that there is expected to only be one context object instance? > > > [2] 11.5.2 > AfterBeanDiscovery#addContext() registers a custom Context object with the container. > (-> no way to add a 'ContextFactory') > > > While this doesn't make much difference for our built in scopes (e.g. OWB currently implements the n-context strategy with a ContextFactory while weld seems to use 1 SessionContext instance, isn't?) it may make a difference for portable extensions. And it is really confusing for people who only want to write an extension providing a Context for a custom scope. So how do you implement addContext() in OWB? Surely it is tricky as it involves cloning the object?

This is probably so obvious it hardly needs to be mentioned, but just in case: it would be great to have the Maven pom for <groupId>javax.enterprise</groupId> <artifactId>cdi-api</artifactId> <version>1.0</version> fixed for the maintenance release. It need to reference the MR of javax.annotation (jsr-250) so that we get @Resource(lookup and javax.annotation.sql. /Johan 2009/12/29 Gavin King <gavin.king(a)gmail.com&gt; Folks, I want to start work on the first CDI maintenance release, and push it out fairly quickly. We've already discussed a couple of things that we wanted in CDI 1.0, but had to delay to the maintenance release: * Bean declaration at constructor level * Abstract producer methods * Injection into static members I want to discuss these things in separate threads. I also have a list of enhancements to the portable extension SPI, which was the least-mature part of the spec, and I would like to discuss with you guys whether some of those enhancements could/should be rolled into the maintenance release. For now, I just want to update the spec with a list of clarifications that have cropped up. Please read over these items and speak up if you have an opinion on any of them! ++ Methods of abstract decorators The CDI 1.0 spec does not define what happens with abstract methods of an abstract decorator class. This was an oversight. We should probably say: * If a decorator class declares an abstract method that is not declared by one of the decorated types, a definition error results * All abstract methods have a container-generated implementation that simply delegates the method call to the delegate object With this definition, I don't think we need any special-casing for abstract methods annotated @Inject, @PostConstruct, etc. ++ Clarify that scope types should not have members The spec should mention that @ScopeType annotations should not have annotation members. Perhaps this should be a definition error. javax.inject.Scope already mentions this. ++ Clarify that parameters of producer and disposer methods are injection points of the producer method bean We say that "....parameters are injection points." We should be clearer and say "....parameters are injection points of the producer method bean." ++ Clarify that not all classes in a bean archive are bean classes We should be clearer and say that you can put non-bean classes (e.g. MDBs) in a bean archive. ++ Clarify that there can be multiple AnnotatedType instances per Java class This is not 100% clear in the spec. ++ Clarify that interceptors/decorators don't apply to producers in resolution rules We say this in the preamble, but we should also mention it in the resolution rules. ++ In lifecycle chapter, clarify creation of interceptors/decorators Not sure precisely what we need to say, but the note in 11.2 is not sufficient, I think. ++ Producers and beans that are under construction I think we need the spec to say something about cases where an injection point of a bean resolves to a producer method of the same bean. The implementation should detect that this is a definition error. It shouldn't try to call a producer method on a non-fully-initialized bean. -- Gavin King gavin.king(a)gmail.com http://in.relation.to/Bloggers/Gavin http://hibernate.org http://seamframework.org _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list weld-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev