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
Adding CDI-129 to MR proposed list ?
by Antoine Sabot-Durand
Someone yesterday mentioned CDI 129 (Clarify behaviour of @ApplicationScoped in EARs) [1] at the end of the meeting.
I didn’t add it to the MR in the 1st place because it seemed a too big issue for a MR, yet it is a popular one.
Do you think it’s realistic to add and discuss this issue ?
[1] https://issues.jboss.org/browse/CDI-129
Antoine
11 years
[JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
by Jens Schumann (JIRA)
[ https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.sy... ]
Jens Schumann commented on CDI-408:
-----------------------------------
Since CDI-404 is probably covered by CDI-1.1-MR would it be possible to include this one in CDI-1.1-MR too?
> bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
> ---------------------------------------------------------------------------
>
> Key: CDI-408
> URL: https://issues.jboss.org/browse/CDI-408
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Beans
> Reporter: Jens Schumann
>
> Right now bean-discovery-mode="annotated" skips beans that are not annotated with an bean-defining annotation even if they contain an observer method or producer method/field. I would not recommend having (not annotated) @Dependent beans with @Observes or @Produces - I just had them by accident while playing around with Wildfly.
> However there are two impacts:
> 1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI runtime will report it. We could optionally document the behavior in the spec, so it's clear to everyone. However I think it's inconsistent, since @Produces may contain a scope (and has a default scope too). Therefore I would vote for @Produces support in bean-discovery-mode="annotated". Of course the enclosing class is not a managed bean that may be injected somewhere.
> 2. Since Observer methods in "not annotated" beans fail silently this can be a major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in bean-discovery-mode="annotated" even if the enclosing bean does not have a bean-defining annotation. Of course the enclosing class is not a managed bean that may be injected somewhere.
> I understand that the proposal above might have negative impacts on class scanning performance in bean-discovery-mode="annotated". However silently failing @Observes can be a major cause of defects that have to be treated because of technical and political reasons. Technical - because it may cause bugs. And political - because in my experience many people are still skeptical that CDI events are a trustworthy achievement[1]. Possibly skipped observer methods won't make live easier.
> If you believe the proposal would kill the original intent of bean-discovery-mode="annotated" please document the impact for Producers and Observers in the spec and even in the XSD.
> --
> [1] I have trained a couple hundred people in using CDI and CDI events. And every time I have to argument against the uncertainty on event delivery: "How do I know which observers are active?", "Who ensures that event's are delivered?"... I personally LOVE events;)
>
> Btw: Which JIRA version is CDI 1.1 Final?
--
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
[JBoss JIRA] (CDI-409) Having @Alternatives for resource definition
by Bruno Borges (JIRA)
[ https://issues.jboss.org/browse/CDI-409?page=com.atlassian.jira.plugin.sy... ]
Bruno Borges commented on CDI-409:
----------------------------------
Antonio, how would the underlying runtime environment know which DataSource to load? And why would only one alternative be enough? Certainly, developers will want to have more options (integration, qa, pre-production).
> Having @Alternatives for resource definition
> --------------------------------------------
>
> Key: CDI-409
> URL: https://issues.jboss.org/browse/CDI-409
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: TBD
> Reporter: Antonio Goncalves
>
> Java EE 6 introduced @DataSourceDefinition and Java EE 7 introduced the same way of defining other resources (JMS factory/destination, Mail factory, JCA connectors....).
> It would be interesting to have @Alternatives working with these resource definitions. For example you could have a default DS for development :
> {code}
> @DataSourceDefinition(
> className = "org.apache.derby.jdbc.EmbeddedDataSource",
> name = "java:global/jdbc/devDS",
> user = "dev",
> password = "dev",
> databaseName = "dev",
> properties = {"connectionAttributes=;create=true"}
> )
> public class DevResources {...}
> {code}
> And another DS that would be used, let say, in production as an alternative :
> {code}
> @Alternative
> @DataSourceDefinition(
> className = "org.apache.derby.jdbc.EmbeddedDataSource",
> name = "java:global/jdbc/prodDS",
> user = "prod",
> password = "prod",
> databaseName = "prod",
> properties = {"connectionAttributes=;create=true"}
> )
> public class ProdResources {...}
> {code}
--
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
[JBoss JIRA] (CDI-409) Having @Alternatives for resource definition
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-409?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-409:
----------------------------------------
Hi
I think it is not a CDI issue but a EE issue. Basically CDI is just a client for these resources which are not CDI beans and these resources mainly rely on JNDI to get an @Alternative behavior. Mixing both is IMO not sane since it will lead to mix and create cycles between specs which finally leads to weird behavior(s) at deployment or worse at runtime.
A convention to declare a resource as cdi bean through a particular qualifier maybe sounds more pragmatic to me, wdyt?
> Having @Alternatives for resource definition
> --------------------------------------------
>
> Key: CDI-409
> URL: https://issues.jboss.org/browse/CDI-409
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: TBD
> Reporter: Antonio Goncalves
>
> Java EE 6 introduced @DataSourceDefinition and Java EE 7 introduced the same way of defining other resources (JMS factory/destination, Mail factory, JCA connectors....).
> It would be interesting to have @Alternatives working with these resource definitions. For example you could have a default DS for development :
> {code}
> @DataSourceDefinition(
> className = "org.apache.derby.jdbc.EmbeddedDataSource",
> name = "java:global/jdbc/devDS",
> user = "dev",
> password = "dev",
> databaseName = "dev",
> properties = {"connectionAttributes=;create=true"}
> )
> public class DevResources {...}
> {code}
> And another DS that would be used, let say, in production as an alternative :
> {code}
> @Alternative
> @DataSourceDefinition(
> className = "org.apache.derby.jdbc.EmbeddedDataSource",
> name = "java:global/jdbc/prodDS",
> user = "prod",
> password = "prod",
> databaseName = "prod",
> properties = {"connectionAttributes=;create=true"}
> )
> public class ProdResources {...}
> {code}
--
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
[JBoss JIRA] (CDI-409) Having @Alternatives for resource definition
by Antonio Goncalves (JIRA)
Antonio Goncalves created CDI-409:
-------------------------------------
Summary: Having @Alternatives for resource definition
Key: CDI-409
URL: https://issues.jboss.org/browse/CDI-409
Project: CDI Specification Issues
Issue Type: Bug
Affects Versions: TBD
Reporter: Antonio Goncalves
Java EE 6 introduced @DataSourceDefinition and Java EE 7 introduced the same way of defining other resources (JMS factory/destination, Mail factory, JCA connectors....).
It would be interesting to have @Alternatives working with these resource definitions. For example you could have a default DS for development :
{code}
@DataSourceDefinition(
className = "org.apache.derby.jdbc.EmbeddedDataSource",
name = "java:global/jdbc/devDS",
user = "dev",
password = "dev",
databaseName = "dev",
properties = {"connectionAttributes=;create=true"}
)
public class DevResources {...}
{code}
And another DS that would be used, let say, in production as an alternative :
{code}
@Alternative
@DataSourceDefinition(
className = "org.apache.derby.jdbc.EmbeddedDataSource",
name = "java:global/jdbc/prodDS",
user = "prod",
password = "prod",
databaseName = "prod",
properties = {"connectionAttributes=;create=true"}
)
public class ProdResources {...}
{code}
--
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
11/25 Meeting notes
by Antoine Sabot-Durand
Hi,
You’ll find meeting notes (asciidoc) below. A cleaner view is available here [1]. Please send me correction if you have any.
= CDI EG meeting 11/25/2013 notes on CDI 1.1.1 MR
In this meeting we came back on CDI-370 : Expand @RequestScoped and @SessionScoped to account for WebSocket and added some other issues.
The following people assisted this meeting :
* Pete Muir (pm)
* Mark Struberg (ms)
* Jozef Hartinger (jh)
* Joseph Bergmark (jb)
* Arne Limburg (al)
* Stuart Douglas (sd) (Websocket expert)
* Phil Zampino (pz) (Java EE EG member)
* Martin Kouba (mk)
* Antoine Sabot-Durand (asd)
== Proposed Agenda
The following agenda was proposed by *asd*
1. Back on Websocket + RequestScoped issue : CDI-370 : Expand @RequestScoped and @SessionScoped to account for WebSocket
Stuart Douglas will be our Guest Star to help us sort out if we can fix this issue on CDI side and if yes, if it’s doable in the MR timeframe
2. If there’s time left let’s discuss the following point :
* CDI-406 Make stereotypes bean defining annotations.
* CDI-404 adding bean-defining annotations for Interceptor while setting bean-discovery-mode=« annotated »
* CDI-389 Revert CDI-85
* CDI-397 Clarify Section 6.6.3 regarding singletons
* CDI-395 Public fields in extensions should not be allowed (also easy to decide)
== Websocket case (https://issues.jboss.org/browse/CDI-370[CDI-370 : Expand @RequestScoped and @SessionScoped to account for WebSocket])
*sd* and *pz* gave their insight on the meaning of Requestscope and Sessionscope in Websocket perspective. It was roughly a synthesis of our http://lists.jboss.org/pipermail/cdi-dev/2013-November/004434.html:[discu... on the ML about the subject
*ms* stressed the fact that implementing one of these solution on CDI impl side could bring performance issue.
*pm* concluded by saying that we should check with Java EE EG if a websocket MR was planned. According to this answer we would statute on this issue
== Other issues
=== https://issues.jboss.org/browse/CDI-406:[CDI-406 Make stereotypes bean defining annotations]
*pm* told there was technical issue to add this to MR (no double scan). No one objected so the issue *is added to the MR*
=== https://issues.jboss.org/browse/CDI-404:[CDI-404 adding bean-defining annotations for Interceptor while setting bean-discovery-mode=« annotated »]
Same as previous. The issue is also *added to the MR*
=== https://issues.jboss.org/browse/CDI-389[CDI-389 Revert CDI-85]
All agreed we can do the revert to CDI 1.0 regarding generic type. But *pm* stressed that we should have a big rework on this for CDI 2.0
=== https://issues.jboss.org/browse/CDI-397[Clarify Section 6.6.3 regarding singletons]
*asd* told that we should go a little beyond and check all occurrences of "singleton" in the spec to clarify if it's an singleton session bean or a singleton scope. As nobody objected the issue was *added to the MR*
=== https://issues.jboss.org/browse/CDI-397[CDI-395 Public fields in extensions should not be allowed]
There was a long discussion on the subject mainly between *pm*, *ms*, *al* and *jh*. Conclusion is that it can bring more problem to correct this issue. *pm* suggested that we defer it. *al* pointed the fact that test on implementation can show that it's not supported already. If it's the case it could be safely added to the MR. So further investigation are needed
[1] http://docgist.nawroth.se/?dropbox-2898173%2FCDI%2520EG%2Fmeetings%2F2013...
Antoine
11 years
[JBoss JIRA] (CDI-398) Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-398?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-398:
--------------------------
Labels: cdi-1.1-mr (was: )
> Clarify that an array with a variable component type or parameterized component type containing wildcards is not a valid bean type
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: CDI-398
> URL: https://issues.jboss.org/browse/CDI-398
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans
> Affects Versions: 1.1.PFD
> Reporter: Marko Lukša
> Labels: cdi-1.1-mr
>
> Section 2.2.1 says:
> {quote}
> Almost any Java type may be a bean type of a bean:
> • A bean type may be an array type.
> {quote}
> and:
> {quote}
> A type variable is not a legal bean type. A parameterized type that contains a wildcard type parameter is not a legal bean type.
> {quote}
> This should be clarified that array types that have a type variable or a parameterized type that contains a wildcard type parameter as the array's component type are also not legal bean types.
> Also, all other sections that mention type variables/wildcards should also be reviewed and, if necessary, updated to also specifically mention array types with these kinds of component types.
--
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