Re: [cdi-dev] Having an official CDI tutorial and user forum
by Antoine Sabot-Durand
Hi Radim,
Allow me to post my answer on the list so every body will benefit of your contribution.
> first of all I would like to let you know that I very appreciate your effort to promote my favourite technology :)
Thanks. I hope we’ll achieve to pursue this promotion effort. It’s always hard to mix highly conceptual technical activity like a spec and promotion / communication at the same time. My feeling is CDI is very overlooked and deserve a bigger community. Community that could help us making it better. Note that I’m not very objective on that topic ;).
> >> I think it would be useful to provide an official CDI 1.1 tutorial on cdi-spec site
> I agree with you a cdi tutorial with a plenty of quickstarts is desperately missing
> something like jboss way quickstarts would be a great addition to cdi-spec.org site
Yes JDF quick starts are nice (and also deal with Deltaspike) but need documentation to introduced them. [1]
Apache team have nice example for CDI as well on TomEE examples [2]
I also remember seeing interesting content on IBM developerworks. I can find them right now.
> >> I have the feeling such content is already nearly written by people in this ML
> recently I tried to find some details on how to properly use @ThreadScoped in java se environment and the only place where I found a working sample was this ML (http://lists.jboss.org/pipermail/weld-dev/2009-December/002016.html)
You may know threadscope is not in the spec, Its specific to Weld, I don’t know if OWB has something like that. Anyway, writing a tutorial on building a thread scope for all imll, could be interesting. Great to show how to add a new scope and promote CDI for SE at the same time.
>
> >> so if you have written introduction tutorial to CDI and agree to be reused on official site it would be great and time saving for me
> I have already written some CDI samples for my colleagues including the one mentioned above
> I would be pleased to supply these samples…
Great. We surely could benefit from them
>
> Sincerely,
> Radim Hanus
>
Thanks again for your commitment
Antoine
[1] http://www.jboss.org/jdf/quickstarts/get-started/
[2] http://tomee.apache.org/examples-trunk/index.html
>
>
>
> 2013/11/18 Antoine Sabot-Durand <antoine(a)sabot-durand.net>
> Hi all,
>
> First excuse my french in previous meeting invites. Obviously Google can speak english to you and keep sending french invitation ;).
>
> I launch this thread in reaction to the FUD or inaccuracies about CDI one can find on the web like this post [1]).
>
> As the spec is quite long to read and very theoretic, I think it would be useful to provide an official CDI 1.1 tutorial on cdi-spec site. It could allows us to be sure that people have an official overview of the spec and could be enhanced with use cases we would encounter on the web (stack overflow or other).
> I have the feeling such content is already nearly written by people in this ML, so if you have written introduction tutorial to CDI and agree to be reused on official site it would be great and time saving for me.
>
> In the same idea of community federation, I think it could be useful to launch a forum (Google group or other) to allow people to ask informal question about CDI and its eco system. People starting using CDI or casual users won’t use this mailing list and all of them think to use site like Stack Overflow. It would also a good mean to enhance our FAQ.
>
> What do you think ?
>
>
> Antoine
>
>
>
> [1] http://blog.frankel.ch/my-case-against-autowiring
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
10 years, 11 months
Observer methods in Java EE
by Laird Nelson
Hello; the CDI specification says that an observer method is a
non-abstract method of a managed bean class or session bean class (or of an
> extension, as defined in [init_events]<http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#init_events>).
> An observer method may be either static or non-static. *If the bean is a
> session bean, the observer method must be either a business method of the
> EJB *or a static method of the bean class.
If I have a business interface that my SLSB implements that is intended to
be an observer method, must @Observes be present on the interface's
method's event parameter, the bean class' method's event parameter, or both?
Thanks,
Best,
Laird
--
http://about.me/lairdnelson
11 years
[JBoss JIRA] (CDI-395) Public fields in extensions should not be allowed
by nathan dennis (JIRA)
[ https://issues.jboss.org/browse/CDI-395?page=com.atlassian.jira.plugin.sy... ]
nathan dennis commented on CDI-395:
-----------------------------------
Antoine... "bring more problems" .... truer words were never spoken.
> Public fields in extensions should not be allowed
> -------------------------------------------------
>
> Key: CDI-395
> URL: https://issues.jboss.org/browse/CDI-395
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.1.PFD
> Reporter: Marko Lukša
>
> Since the container must provide an @ApplicationScoped bean for every extension and since a proxy must be injected into injection points requesting this bean, it should be clear that extensions should not be allowed to have public fields. The spec doesn't specify this explicitly, but it should - like it does for non-dependent managed beans.
> The container should treat this as a definition error, otherwise people may end up accessing these public fields of extensions and getting weird errors.
> See also WELD-1474
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
Maintenance Release preparation final
by Antoine Sabot-Durand
Hi all,
You’ll find yesterday’s meeting notes here : http://www.cdi-spec.org/news/2013/12/16/EG-meeting/
In Jira, I created the 1.2 Proposed version and affected all the tickets to it (you can access the list with this short link [1]).
Please double check the content of the list as it should normally be closed by now. So a mistake could cost a lot when the MR will begin.
There’s still a pending issue (even if I added it to the list) : CDI-411 CDI conversation activation conflicts with the Servlet spec [2]. Jozef has to investigate this point to see if we can safely keep it in the MR.
MR will be officially launched on jan 6th week at this time this list will be locked.
Thank you for the preparation work and your coming work on this MR.
Antoine
[1] http://s.shr.lc/1fBf5ix
[2] https://issues.jboss.org/browse/CDI-411
11 years
[JBoss JIRA] (CDI-376) BeanManager#getProducerFactory return type differs between API and spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-376?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-376:
-------------------------------------
Fix Version/s: 1.2
> BeanManager#getProducerFactory return type differs between API and spec
> -----------------------------------------------------------------------
>
> Key: CDI-376
> URL: https://issues.jboss.org/browse/CDI-376
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Javadoc and API
> Affects Versions: 1.1.PFD
> Reporter: Mark Struberg
> Priority: Critical
> Fix For: 1.2
>
>
> return type differs between API and spec wording for both BeanManager#getProducerFactory methods.
> 1st is API git, 2nd is spec version:
> public <X> ProducerFactory<X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);
> public <X> ProducerFactory<? super X> getProducerFactory(AnnotatedMethod<? super X> method, Bean<X> declaringBean);
> They differ in the return type:
> ProducerFactory<X> vs
> ProducerFactory<? super X>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
