beans.xml quiz for Friday afternoon
by Martin Kouba
Hi all,
today I struggled with weird beans.xml parsing problems and I found out
that this part of CDI might deserve some clarification. Below are few
examples. And not all of them have obvious interpretation.
Also note that the spec still contains invalid beans.xml snippets (see
also CDI-449).
1. empty beans.xml marker file
- spec VALID, bean-discovey-mode="ALL"
- XSD validation not needed
2. <beans/>
- spec VALID, bean-discovey-mode="ALL"
- XSD validation not possible
3. <beans xmlns="http://java.sun.com/xml/ns/javaee">
- spec VALID, Java EE 6 namespace, ie. CDI 1.0, bean-discovey-mode="ALL"
- XSD validation OK (against beans_1_0.xsd)
4. <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee">
- spec VALID
- XSD validation ERROR - Java EE 7 namespace, i.e. CDI 1.1+ and
bean-discovey-mode attribute is required
- note that version is defaulted to "1.1" (and e.g. SAXParser fills this
value automatically)
- what's the correct bean-discovey-mode? => I would expect ANNOTATED
because we're in EE 7 and it's the default bean discovery mode
- bean-discovey-mode attribute is required, not defaulted
- current Weld behavior: ALL
5. <beans xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.1">
- spec INVALID, "A bean archive which contains a beans.xml file with
version 1.1 (or later) must specify the bean-discovey-mode attribute.
The default value for the attribute is annotated."
- XSD validation ERROR, bean-discovey-mode attribute is required
- what's the correct bean-discovey-mode? => I would expect ANNOTATED
- current Weld behavior: ALL
6. <beans version="1.1">
- spec INVALID, the same as above
- XSD validation not possible
- what's the correct bean-discovey-mode? => I would expect ANNOTATED
- current Weld behavior: ALL
7. <beans version="1.1" bean-discovery-mode="annotated">
- spec VALID, bean-discovey-mode="ANNOTATED"
- XSD validation not possible
8. <beans version="1.1" bean-discovery-mode="all"
xmlns="http://xmlns.jcp.org/xml/ns/javaee">
- spec VALID, bean-discovey-mode="ALL"
- XSD VALID
We may consider adding default value for bean-discovey-mode, and maybe
rewording the spec text. But I'm no XML guru so maybe I'm missing something.
Thanks,
Martin
7 years, 6 months
[JBoss JIRA] (CDI-523) CDI spec tries to dispose a container-managed entity manager.
by Martin Andersson (JIRA)
[ https://issues.jboss.org/browse/CDI-523?page=com.atlassian.jira.plugin.sy... ]
Martin Andersson commented on CDI-523:
--------------------------------------
There is one provided on the second link in the post. This example look up an application-managed entity manager (with disposer):
{code:java}
@RequestScoped
public class EntityManagerProducer
{
@PersistenceUnit
EntityManagerFactory factory;
@Produces
@RequestScoped
public EntityManager newEntityManager() {
return factory.createEntityManager();
}
public void closeEntityManager(@Disposes EntityManager em) {
em.close();
}
}
public class EntityManagerConsumer
{
@Inject
EntityManager em;
// ...
}
{code}
> CDI spec tries to dispose a container-managed entity manager.
> -------------------------------------------------------------
>
> Key: CDI-523
> URL: https://issues.jboss.org/browse/CDI-523
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final, 1.1.Final
> Reporter: Martin Andersson
> Assignee: John Ament
> Fix For: 2.0 .Final
>
>
> Section "3.5.2. Declaring a disposer method" has this example:
> {code:java}
> public class Resources {
> @PersistenceContext
> @Produces @UserDatabase
> private EntityManager em;
>
> public void close(@Disposes @UserDatabase EntityManager em) {
> em.close();
> }
> }
> {code}
> The disposer method above call {{EntityManager.close()}} on a container-managed entity manager which result in an {{IllegalStateException}} being thrown *and* the entity manager remains open. This behavior is expected as the JPA specification forbids application code to close a container-managed entity manager. JPA 2.1, section "7.9.1 Container Responsibilities" says:
> {quote}
> The container must throw the IllegalStateException if the application calls EntityManager.close on a container-managed entity manager.
> {quote}
> This has been proved [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/maste...] and a theoretical walkthough surrounding entity managers combined with CDI scopes is available [here|https://github.com/MartinanderssonDotcom/java-ee-concepts/blob/maste...].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-449) beans.xml examples are not valid
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-449?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba reassigned CDI-449:
--------------------------------
Assignee: Tomas Remes
> beans.xml examples are not valid
> --------------------------------
>
> Key: CDI-449
> URL: https://issues.jboss.org/browse/CDI-449
> Project: CDI Specification Issues
> Issue Type: Bug
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
> Assignee: Tomas Remes
> Fix For: 2.0 .Final
>
>
> The {{beans.xml}} examples in "5.1.1. Declaring selected alternatives", "8.2.2. Decorator enablement and ordering for a bean archive" and "9.4. Interceptor enablement and ordering" (which contain a reference to beans_1_1.xsd) are not valid - {{bean-discovery-mode}} attribute is required. I think it would be appropriate to specify the version attribute as well.
> The last {{beans.xml}} example in "12.4.2. Exclude filters" does not even define the reference to an XSD. Again, I believe the version and bean-discovery-mode attributes should be specified.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-627) fix wording regression for beans.xml alternative check introduced in 1.2
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-627?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-627:
---------------------------------
This will need additional fix - see my comment https://github.com/cdi-spec/cdi/pull/309
> fix wording regression for beans.xml alternative check introduced in 1.2
> ------------------------------------------------------------------------
>
> Key: CDI-627
> URL: https://issues.jboss.org/browse/CDI-627
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Concepts
> Affects Versions: 1.2.Final
> Reporter: Mark Struberg
> Assignee: Mark Struberg
> Fix For: 2.0 .Final
>
>
> My scenario is the following:
> I have an @Alternative MockMailService class which should only be used during testing to not send out 5k mails to customers and employees when running the unit and integration test suite.
> {code}
> @Alternative
> @ApplicationScoped
> @Exclude(ifProjectStage=Production.class)
> public class MockMailService implements MailService {...}
> {code}
> Of course I only need to activate it in beans.xml:
> {code}
> <beans>
> <alternatives>
> <class>org.acme.MockMailService</class>
> </alternatives>
> </beans>
> {code}
> This is perfectly fine in CDI 1.0 but might be interpreted as not be allowed in the CDI 1.2 wording paragraph 5.1.1.2. "Declaring selected alternatives for a bean archive".
> Please note that we introduced a check in CDI 1.0 purely to help the customer eagerly detect possible wrong configuration. E.g. if he simply has a typo in the classname. It was _not_ intended to restrict useful use cases!
> What the intention was: all is fine IF one of
> * There exists a class T with the given name
> * That class T (or a contained producer field or producer method) is annotated with @Alternative
> * There is a Bean<T> with isAlternative() == true
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
Open PR validation
by Antoine Sabot-Durand
Hi all,
As the feature freeze date approach we have a lot of PR pending. Some are
big ones and ask a lot of discussion, some are rather obvious.
For these PR, I started to merge them if they were 1 week old and have at
least one person ok with its content. I'd prefer to have more than one
review of these, but we have a schedule to meet.
Try to check these small PR to be sure that we don't miss something, but
after one week with only positive feedback there will be merged.
Antoine
7 years, 6 months
[JBoss JIRA] (CDI-616) Injection point declared as transient is not useful
by Emily Jiang (JIRA)
[ https://issues.jboss.org/browse/CDI-616?page=com.atlassian.jira.plugin.sy... ]
Emily Jiang commented on CDI-616:
---------------------------------
On f2f, the suggestion is to add "Injection in transient field is not supported. Non portable behaviour will occur" under 5.2.5.
After some more thinking, I still think what I proposed originally is better, which is to add the following sentences under 5.5.7.
"
If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance<> injection point is the preferred approach.
"
Thoughts?
> Injection point declared as transient is not useful
> ---------------------------------------------------
>
> Key: CDI-616
> URL: https://issues.jboss.org/browse/CDI-616
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Concepts
> Affects Versions: 1.2.Final
> Environment: n/a
> Reporter: Emily Jiang
> Priority: Minor
> Fix For: 2.0 .Final
>
>
> An injection point declared as 'transient' is not useful, due to the fact of after bean's passivation, the transient field will not be reinjected and its value will be lost. This causes confusion. See Weld forum discussion [link title|https://developer.jboss.org/thread/179486]. In the section 5.5.7, how about to make the following changes?
> The isTransient() method returns true if the injection point is a transient field, and
> false otherwise. If the injection point represents a dynamically obtained instance then the
> isTransient() method returns true if the Instance injection point is a transient field, and
> false otherwise.
> =>
> The isTransient() method returns true if the injection point is a transient field, and
> false otherwise. If the injection point represents a dynamically obtained instance then the
> isTransient() method returns true if the Instance injection point is a transient field, and
> false otherwise. If this injection point is declared as transient, after bean's passivation, the value will not be restored. Instance injection point is the preferred approach.
> Any other better suggestions?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-497) session scope doesn't follow session lifecycle
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-497?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-497:
----------------------------------
[~agoncal] Yes, but the quoted sentence only applies to session timeouts. Servlet spec does not mention {{HttpSession.invalidate()}} at all. I think we should ask Servlet EG first.
[~antoinesabot-durand] Isn't this a candidate for CDI 2.1 which targets Java EE 8?
> session scope doesn't follow session lifecycle
> ----------------------------------------------
>
> Key: CDI-497
> URL: https://issues.jboss.org/browse/CDI-497
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
> Fix For: 2.0 .Final
>
>
> ATM session destroyed event is bound to the request. this means a logout will not be able to access the right session when destroyed since most of the time logout = session destruction and then you can recreate a session (login case).
> Would be great to align CDI scopes - and then events - to the real lifecycle of the underlying observed event.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-495) What happens if an illegal bean type is found in the set of bean types
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-495?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-495:
---------------------------------
I am just wondering if it's worth of specifying. Wasn't there any special case when it is problematic?
> What happens if an illegal bean type is found in the set of bean types
> ----------------------------------------------------------------------
>
> Key: CDI-495
> URL: https://issues.jboss.org/browse/CDI-495
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Martin Kouba
> Fix For: 2.0 .Final
>
>
> The spec clearly defines what the legal bean types are (2.2.1. Legal bean types). and also that an illegal injection point type results in definition error (5.2.3. Legal injection point types). However, it's not clear what should happen if an illegal bean type is found in the set of bean types and *is not used* in an injection point. I think that it would be reasonable to just ignore the type (and possibly log some warning).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
[JBoss JIRA] (CDI-592) Consider adding ObserverMethod.notify() method which also accepts EventMetadata
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-592?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba reassigned CDI-592:
--------------------------------
Assignee: Martin Kouba
> Consider adding ObserverMethod.notify() method which also accepts EventMetadata
> -------------------------------------------------------------------------------
>
> Key: CDI-592
> URL: https://issues.jboss.org/browse/CDI-592
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Martin Kouba
> Assignee: Martin Kouba
> Fix For: 2.0 .Final
>
>
> {code:java}
> // Make the original method also default so that new impls don't need to implement two methods
> default void notify(T event) {
> // No-op
> }
> // The container should always call this method...
> default void notify(T event, EventMetadata metadata) {
> notify(event);
> }
> {code}
> This should not break existing implementations. The truth is a custom impl will not be forced to implement any {{notify()}} method. But I think the benefits are worth it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 6 months
