[JBoss JIRA] (CDI-379) Clarify life cycle of RequestScoped
by Jens Schumann (JIRA)
[ https://issues.jboss.org/browse/CDI-379?page=com.atlassian.jira.plugin.sy... ]
Jens Schumann commented on CDI-379:
-----------------------------------
As stated in CDI-370 I still believe the CDI spec is way to verbose regarding scopes and related APIs. I think it would be better to move most of the stuff to the related specs (servlet, ejb, ...) or even the Java EE umbrella. Same applies to CDI-380.
> Clarify life cycle of RequestScoped
> -----------------------------------
>
> Key: CDI-379
> URL: https://issues.jboss.org/browse/CDI-379
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Joseph Snyder
> Priority: Minor
>
> This is one of the areas where the CDI spec could be clearer. It defines
> the points where "some" request scope is active, and where "some" request
> scope is destroyed, but it doesn't clearly state what the span of a particular
> request context is. You sort of have to work backwards and figure it out.
> Update the spec to indicate when a particular request scope is
> created, what operations it's active during, and when it's destroyed.
--
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, 6 months
[JBoss JIRA] (CDI-381) Additional implementations of Request Context
by Joseph Snyder (JIRA)
Joseph Snyder created CDI-381:
---------------------------------
Summary: Additional implementations of Request Context
Key: CDI-381
URL: https://issues.jboss.org/browse/CDI-381
Project: CDI Specification Issues
Issue Type: Clarification
Reporter: Joseph Snyder
Priority: Minor
Suppose another spec wanted to define when @RequestScoped applied to its
operations, how would it do that? The javadocs for @RequestScoped seem to
be an exhaustive list, not allowing the scope to be used in other contexts.
The javadocs need to indicate that the scope can be active at other
times beyond what the spec describes. It can be tricky to do that in a
way that doesn't allow people to implement the currently defined scopes
incorrectly.
--
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, 6 months
[JBoss JIRA] (CDI-380) Clarify SessionScoped
by Joseph Snyder (JIRA)
Joseph Snyder created CDI-380:
---------------------------------
Summary: Clarify SessionScoped
Key: CDI-380
URL: https://issues.jboss.org/browse/CDI-380
Project: CDI Specification Issues
Issue Type: Clarification
Reporter: Joseph Snyder
Priority: Minor
The javadocs say:
The request context is destroyed:
- at the end of the servlet request, after the service() method, all
doFilter() methods, and all requestDestroyed() and onComplete()
notifications return,
...
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.
Those definitions are different.
The session context rule seems to be a combination of "or" items that
include some "and" items. It's difficult to parse. It would be clearer
if it was written as a list. And, like request scoped, it would be clearer
if it described when the session scope/context is created.
--
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, 6 months
[JBoss JIRA] (CDI-379) Clarify life cycle of RequestScoped
by Joseph Snyder (JIRA)
[ https://issues.jboss.org/browse/CDI-379?page=com.atlassian.jira.plugin.sy... ]
Joseph Snyder updated CDI-379:
------------------------------
Issue Type: Clarification (was: Bug)
Priority: Minor (was: Major)
> Clarify life cycle of RequestScoped
> -----------------------------------
>
> Key: CDI-379
> URL: https://issues.jboss.org/browse/CDI-379
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Joseph Snyder
> Priority: Minor
>
> This is one of the areas where the CDI spec could be clearer. It defines
> the points where "some" request scope is active, and where "some" request
> scope is destroyed, but it doesn't clearly state what the span of a particular
> request context is. You sort of have to work backwards and figure it out.
> Update the spec to indicate when a particular request scope is
> created, what operations it's active during, and when it's destroyed.
--
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, 6 months
[JBoss JIRA] (CDI-379) Clarify life cycle of RequestScoped
by Joseph Snyder (JIRA)
Joseph Snyder created CDI-379:
---------------------------------
Summary: Clarify life cycle of RequestScoped
Key: CDI-379
URL: https://issues.jboss.org/browse/CDI-379
Project: CDI Specification Issues
Issue Type: Bug
Reporter: Joseph Snyder
This is one of the areas where the CDI spec could be clearer. It defines
the points where "some" request scope is active, and where "some" request
scope is destroyed, but it doesn't clearly state what the span of a particular
request context is. You sort of have to work backwards and figure it out.
Update the spec to indicate when a particular request scope is
created, what operations it's active during, and when it's destroyed.
--
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, 6 months
[JBoss JIRA] (CDI-378) clarify behavior regarding concurrency utilities in javaee
by Romain Manni-Bucau (JIRA)
Romain Manni-Bucau created CDI-378:
--------------------------------------
Summary: clarify behavior regarding concurrency utilities in javaee
Key: CDI-378
URL: https://issues.jboss.org/browse/CDI-378
Project: CDI Specification Issues
Issue Type: Clarification
Reporter: Romain Manni-Bucau
the jsr 236 defines "contexts" (more or less thread locals to be concrete) to be saved when using the API (ContextService, ManagedExecutorService and children) and if is included in these contexts is unclear ATM (it sounds logical to say no since it is not the case for @Asynchronous, EJB timer etc...)
Would be great to make it very explicit IMO
--
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, 6 months
concurrecy utilities 4 EE and cdi scopes
by Romain Manni-Bucau
Hi guys,
reading concurrency utilities i understand the container should propagate
the caller "context" (no link with cdi contexts) but it doesn't defined
explicitly what it is. So here is the question: are CDI contexts (scopes)
included in this "context"? - i think to request, session, conversation
scopes in particular.
Since you can submit a request scope bean (bad idea but allowed
explicitely) i tend to think it should be done but then the request scope
is broken (since that's a thread scope by design) so not sure where is the
issue if there is one or if i missed something.
Any idea?
*Romain Manni-Bucau*
*Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
*Blog: **http://rmannibucau.wordpress.com/*<http://rmannibucau.wordpress.com/>
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*
11 years, 6 months
[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Reuben Pasquini (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Reuben Pasquini updated CDI-377:
--------------------------------
Description:
The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
Adding a dependency on a jar that uses guice or whatever in a javase environment
to a war deployed to a jee7 container
results in CDI processing annotated classes intended for
app-managed injection. See this ticket filed with guava for a concrete example:
https://code.google.com/p/guava-libraries/issues/detail?id=1433
was:
The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
Adding a dependency on such a package to code deployed to a jee7 container
results in CDI processing annotated classes intended for
app-managed injection. See this ticket filed with guava for a concrete example:
https://code.google.com/p/guava-libraries/issues/detail?id=1433
> automatic JSR-330 annotation processing problematic
> ---------------------------------------------------
>
> Key: CDI-377
> URL: https://issues.jboss.org/browse/CDI-377
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.PFD
> Environment: glassfish-4
> Reporter: Reuben Pasquini
> Labels: CDI, guava, guice
>
> The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
> Adding a dependency on a jar that uses guice or whatever in a javase environment
> to a war deployed to a jee7 container
> results in CDI processing annotated classes intended for
> app-managed injection. See this ticket filed with guava for a concrete example:
> https://code.google.com/p/guava-libraries/issues/detail?id=1433
--
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, 6 months
[JBoss JIRA] (CDI-376) BeanManager#getProducerFactory return type differs between API and spec
by Mark Struberg (JIRA)
Mark Struberg created CDI-376:
---------------------------------
Summary: 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
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, 6 months