JavaLand
by Thorben Janssen
Hi,
I know I'm asking a little bit late, but is anyone else attending the JavaLand conference this week?
Would be nice to meet some of you in person. You can find me at the J-Pardy quiz tomorrow evening or send me a message to arrange a meeting.
Regards,
Thorben
PS: I will miss the weekly meeting tomorrow :(
9 years, 1 month
What about @AsyncObserves ?
by Antoine Sabot-Durand
Hi guys,
So it seems impossible to avoid opt-in on the observer side for the sake of awkward compatibility.
Adding a member to @Observes could also be a source of issues when old CDI lib will be used with CDI 2.0 runtime. Some of us (including me) don’t want to add an @Async annotation to CDI spec, so perhaps we should add an async alternative to @Observes with an @AsyncObserves or @ObservesAsync ?
So it would be
public void myObserver(@AsyncObserves payload) {}
instead of
@Async
public void myObserver(@Observes payload) {}
Pros :
- it’s a cleaner way to manage the opt-in than to put 2 annotations or add a member to an existing one
- it could have new members related to async behavior (context propagation, concurrent scenario, etc…)
- As it won’t be in legacy code no risk to see old observers called asynchronously
Cons :
- Still not clear for users when fire() is called to see @AsyncObserves launched synchronously
- Yet another annotation added
wdyt ?
Antoine
9 years, 1 month
[JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-518:
-----------------------------------
Oki, getting tricky now. I think we should take a step back and finally do our homework regarding EAR handling.
* What classes are seen where.
* How do we handle/deal with isolation and visibility constraints of CDI running in EARs.
* How does Extension visibility look like
* Which classes should get delivered to which Extension
* getBeans in EARs
* @Named in EARs (thats a TOTAL mess right now)
* getInterceptors, decorators etc in EARs
...
After that the observer resolution will solve itself pretty quickly.
> Clarify boundaries of the ServletContext event
> ----------------------------------------------
>
> Key: CDI-518
> URL: https://issues.jboss.org/browse/CDI-518
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Reporter: Jozef Hartinger
>
> {quote}
> An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application
> context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired
> when the application is destroyed. The event payload is:
> • the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle
> • any java.lang.Object for other types of application.
> {quote}
> Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-518:
-------------------------------------
Do you mean "8.3 Class Loading Requirements"? If so then don't forget that ServletContext is not an application class. Therefore, this needs to be defined explicitly.
> Clarify boundaries of the ServletContext event
> ----------------------------------------------
>
> Key: CDI-518
> URL: https://issues.jboss.org/browse/CDI-518
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Reporter: Jozef Hartinger
>
> {quote}
> An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application
> context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired
> when the application is destroyed. The event payload is:
> • the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle
> • any java.lang.Object for other types of application.
> {quote}
> Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-518:
-----------------------------------
The JavaEE umbrella spec says so in the isolation chapter. They are not referring to Bean<T> of course, but class visibility. But it essentially boils down to the same.
> Clarify boundaries of the ServletContext event
> ----------------------------------------------
>
> Key: CDI-518
> URL: https://issues.jboss.org/browse/CDI-518
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Reporter: Jozef Hartinger
>
> {quote}
> An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application
> context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired
> when the application is destroyed. The event payload is:
> • the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle
> • any java.lang.Object for other types of application.
> {quote}
> Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.sy... ]
Jozef Hartinger commented on CDI-518:
-------------------------------------
{quote}In fact if WAR1 calls BeanManager#resolveObserverMethods then the ObserverMethods from WAR2 must not even get returned.{quote}
Based on what? Your conclusion is reasonable but the spec does not say so. Therefore, I raised this clarification issue.
> Clarify boundaries of the ServletContext event
> ----------------------------------------------
>
> Key: CDI-518
> URL: https://issues.jboss.org/browse/CDI-518
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Reporter: Jozef Hartinger
>
> {quote}
> An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application
> context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired
> when the application is destroyed. The event payload is:
> • the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle
> • any java.lang.Object for other types of application.
> {quote}
> Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-518?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-518:
-----------------------------------
I don't think we need to change anything. Section "10.3 Observer resolution" defines
{quote}
An event is delivered to an observer method if:
• The observer method belongs to an enabled bean.
{quote}
In fact if WAR1 calls BeanManager#resolveObserverMethods then the ObserverMethods from WAR2 must not even get returned.
Also see 10.5 "Observer notification"
{quote}
• If there is no context active for the scope to which the bean declaring the observer method belongs, then the observer method should not be called.
{quote}
We can assume that the 'ApplicationContext' of beans from the other webapp (e.g. WAR2) is not active during a request to WAR1. This might be a bit too implicit, but there are already multiple other reasons why observers from WAR2 should not get this event from WAR1.
> Clarify boundaries of the ServletContext event
> ----------------------------------------------
>
> Key: CDI-518
> URL: https://issues.jboss.org/browse/CDI-518
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Events
> Reporter: Jozef Hartinger
>
> {quote}
> An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application
> context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired
> when the application is destroyed. The event payload is:
> • the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle
> • any java.lang.Object for other types of application.
> {quote}
> Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (CDI-518) Clarify boundaries of the ServletContext event
by Jozef Hartinger (JIRA)
Jozef Hartinger created CDI-518:
-----------------------------------
Summary: Clarify boundaries of the ServletContext event
Key: CDI-518
URL: https://issues.jboss.org/browse/CDI-518
Project: CDI Specification Issues
Issue Type: Clarification
Components: Events
Reporter: Jozef Hartinger
{quote}
An event with qualifier @Initialized(ApplicationScoped.class) is fired when the application
context is initialized and an event with qualifier @Destroyed(ApplicationScoped.class) is fired
when the application is destroyed. The event payload is:
• the ServletContext if the application is a web application deployed to a Servlet container, or Conversation context lifecycle
• any java.lang.Object for other types of application.
{quote}
Unlike dependency injection, the spec does not define any visibility boundaries for events. It could therefore be implied that in an EAR a web application could observe the ServletContext event for a different web application. This obviously does not seem right and the spec should explicitly define the expected behavior.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
On @Observes for async events
by Antoine Sabot-Durand
Hi all,
Yesterday we had another meeting to try to find a better solution than explicitly activating async event on observer, without no success. I understand that we should go on on this feature so what I suggest is to have a meeting (an hangout) with people that want to try to find a better solution. If we find something we’ll do a last proposal, and in all case we’ll adopt the woking solution next week for this point. People interested with this please manifest yourself.
If we have to go with opt-in (have to explicitly declare an observer supporting async event) we also have to validate the decision to use a member in @Observes (as it was decided before) or go back on that as mMark keep asking by introducing a new annotation to add on the observer (@Async or something similar). As I said when we discussed this point, I prefer the member in @Observes but we may have overlooked issues linked to backward compatibility.
A third solution might be to introduce an @ObserveAsync to declare an asynchronous capable observer…
I’m waiting for active feedback from you to find the best solution taking ALL aspects (not only the technicals one) into account.
Thanks,
Antoine
9 years, 1 month
Early Draft 1
by Antoine Sabot-Durand
Hi All,
I talked about it if before but we should really start preparing our Early Draft. I’d like to release it for second half of April and put the big stuff we are working on right now:
- Java SE / EE split
- Async Events
- Java SE support
An early draft is not a finished document, new features we’ll add there could be changed later or totally disappear if we’re not happy with it. It’s a great way to show our work to the greater community and have feedback. Certainly a way to get a higher point of view on our recent discussions ;).
We’ll take a moment during our next meeting to deal with that coming release.
Antoine
9 years, 1 month
