[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Jozef Hartinger commented on CDI-18:
------------------------------------
{quote}Even JBossAS nor GlassFish are NOT following the strict CDI-1.1 rules right now because they are unusable!{quote}
Alternatives are enabled as required by the spec (per bean archive) in JBoss AS (not sure about GF). Could you provide evidence supporting your statement?
> Global enablement of interceptors, decorators and alternatives
> --------------------------------------------------------------
>
> Key: CDI-18
> URL: https://issues.jboss.org/browse/CDI-18
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans, Decorators, Interceptors, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PRD
>
>
> Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml).
> Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder!
> This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml.
> Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment!
--
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
12 years
EG meeting today cancelled
by Pete Muir
All,
As discussed last week until we resolve the issue on which we are currently voting, most topics do not require discussion. Therefore I'm cancelling todays meeting as I believe the time is more productively spent actually making changes to the spec!
12 years
cyclic references
by Mark Struberg
Hi Folks!
I know we already discussed that cyclic references in @PostConstruct and @Inject methods are not allowed (btw, did we also nail this down in the spec properly? This is implicitly defined in commons-annotations).
But what about @PreDestroy? As the destroy order is not defined for normalscoped beans it could happen that a bean already got wiped and destroyed while another one likes to access it. So it's not only a problem of cycles, but might also happen without.
sample:
@RequestScoped
public class BeanA {
@Inject BeanB b;
@PreDestroy
public void destroyMe() {
b.dosomething();
}
}
and
@RequestScoped
public class BeanB {
public void dosomething() {..}
@PreDestroy
public void dropDatabaseConnection() {...}
}
Now lets imagine that BeanB got destroyed earlier than BeanA ....
It's atm purely random. Imo this is ok, but should we point users to this behaviour?
LieGrue,
strub
12 years
[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Pete Muir commented on CDI-18:
------------------------------
Preserving backwards compatibility is not optional.
Please propose an alternative approach that preserves backwards compatibility.
> Global enablement of interceptors, decorators and alternatives
> --------------------------------------------------------------
>
> Key: CDI-18
> URL: https://issues.jboss.org/browse/CDI-18
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans, Decorators, Interceptors, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PRD
>
>
> Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml).
> Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder!
> This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml.
> Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment!
--
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
12 years
[JBoss JIRA] (CDI-228) Clarify that _all_ @Dependent beans created for a containers method invocation will get destroyed after the method exits
by Mark Struberg (JIRA)
Mark Struberg created CDI-228:
---------------------------------
Summary: Clarify that _all_ @Dependent beans created for a containers method invocation will get destroyed after the method exits
Key: CDI-228
URL: https://issues.jboss.org/browse/CDI-228
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts
Affects Versions: 1.1.EDR1
Reporter: Mark Struberg
This clarification is intended for all methods which gets invoked by the CDI container and create a new @Dependent contextual instance especially for this invocation. This can happen in @Observes, @Produces, @Disposal and @Inject methods as well as in @Inject contructors. Basically any @Dependent method-parameter InjectionPoint.
Despite it's atm not specified whether this @Dependent instance will get stored, most containers store it in the CreationalContext of the bean containing the invoked method. This behaviour can lead to mem leaks and non-serializibility issues.
TASK: Define that any @Dependent contextual instance will get properly destroyed after such method invocations.
There are 2 things we need to think about:
1.) any @PreDestroy method of those beans will get invoked after the method invocation, even if the @Dependent instance will stored away in a member field and still being used later. This will not make any problems in most cases. We just need to make people aware that this will happen.
2.) As any Decorator or Interceptor is also an @Dependent instance on our 'temporary' created @Dependent method parameter, those Interceptors and Decorators will _not_ be available after the method invocation. Storing away this bean and re-using it later will probably cause an Exception.
I still think this is a small problem compared to creating tons of mem leaks. There are quite a few workarounds possible:
*) Instead of @Inject methods you can use @Inject field + @PostConstruct to initialize it.
*) We might add an additional annotation which denotes either @Transactional or au contraire: @Keep for the method-param InjectionPoint
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Mark Struberg commented on CDI-18:
----------------------------------
PS:
> 2.) In the legacy mode (enablement for bean archive)
There should be no legacy mode at all. This was just horribly broken and unmaintainable. I see no whatever sense in keeping this. And the argument with backward compatibility is moot as no user ever used that. Even JBossAS nor GlassFish are NOT following the strict CDI-1.1 rules right now because they are unusable!
> Global enablement of interceptors, decorators and alternatives
> --------------------------------------------------------------
>
> Key: CDI-18
> URL: https://issues.jboss.org/browse/CDI-18
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans, Decorators, Interceptors, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PRD
>
>
> Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml).
> Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder!
> This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml.
> Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment!
--
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
12 years
[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Mark Struberg reopened CDI-18:
------------------------------
sorry, the wording of 5.1.1 is out of any concept.
This didn't get easier but is now almost impossible to implement!
Things like
{quote}
An alternative selected for an application may be deselected for a bean archive using the <alternatives> element of the beans.xml file of the bean archive. The <alternatives> element contains a list of bean classes and stereotypes, along with a disabled flag. An alternative is not selected for the bean archive if either..
{quote}
That complicates the useless and utter broken rules of CDI-1.0 even more. Please let's just get rid of those BDA implications and focus on solving the modularity properly.
> Global enablement of interceptors, decorators and alternatives
> --------------------------------------------------------------
>
> Key: CDI-18
> URL: https://issues.jboss.org/browse/CDI-18
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans, Decorators, Interceptors, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PRD
>
>
> Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml).
> Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder!
> This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml.
> Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment!
--
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
12 years
[JBoss JIRA] (CDI-296) Miscellaneous issues
by Jozef Hartinger (JIRA)
Jozef Hartinger created CDI-296:
-----------------------------------
Summary: Miscellaneous issues
Key: CDI-296
URL: https://issues.jboss.org/browse/CDI-296
Project: CDI Specification Issues
Issue Type: Bug
Affects Versions: 1.1.PRD
Reporter: Jozef Hartinger
Assignee: Pete Muir
Priority: Minor
Fix For: 1.1 (Proposed)
A number of trivial issues popped out:
* "If the runtime type of the event object is assignable to the type of a container lifecycle event, IllegalArgumentException is thrown." should be "*an* IllegalArgumentException is thrown."
** affects 10.3.1 and 11.3.10
* 11.2 says: "The instance returned by produce may be a proxy." should be: "The instance returned by *produce()* may be a proxy." - the method name should be marked as literal
* 8.2 the first occurrence of expression "enabled flag" actually refers to a disable flag (enabled="false")
--
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
12 years, 1 month
[JBoss JIRA] (CDI-297) Incorporate statements from Instance.destroy() javadoc into the spec
by Martin Kouba (JIRA)
Martin Kouba created CDI-297:
--------------------------------
Summary: Incorporate statements from Instance.destroy() javadoc into the spec
Key: CDI-297
URL: https://issues.jboss.org/browse/CDI-297
Project: CDI Specification Issues
Issue Type: Clarification
Reporter: Martin Kouba
Priority: Minor
Instance.destroy() javadoc:
{quote}
All built-in contexts support destroying bean instances.
{quote}
{quote}
UnsupportedOperationException is thrown if the active context object for the scope type of the bean does not support destroying bean instances
{quote}
IMHO both of the sentences should be in the spec as well.
--
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
12 years, 1 month
[JBoss JIRA] (CDI-284) Clarify AlterableContext corner cases
by Jozef Hartinger (JIRA)
Jozef Hartinger created CDI-284:
-----------------------------------
Summary: Clarify AlterableContext corner cases
Key: CDI-284
URL: https://issues.jboss.org/browse/CDI-284
Project: CDI Specification Issues
Issue Type: Clarification
Components: Contexts, Resolution
Affects Versions: 1.1.PRD
Reporter: Jozef Hartinger
Assignee: Pete Muir
Fix For: 1.1 (Proposed)
There are some corner cases that are not well specified and should be improved:
h3. Dependent scope
The context for the @Dependent scope (DependentContext hereafter) is required to implement the AlterableContext interface. However, it is not possible to properly execute the DependentContext.destroy() method since the CreationalContext is not known.
h3. Context not active
The Javadoc for AlterableContext should say that the methods throws ContextNotActiveException if the method is invoked on a Context that is not active.
h3. reflect CDI-24
The spec should require the container to use a serializable Contextual not only for Context.get() methods but also for AlterableContext.destroy()
https://issues.jboss.org/browse/CDI-24
h3. Illegal arguments
I am wondering whether the spec should be more strict and require better validation of AlterableContext.destroy() and Instance.destroy() parameters.
For example:
{code:JAVA}
instance.destroy(new Object());
{code}
should probably be considered an illegal argument. That would at least be expected by users I guess. On the other hand, such validation would disallow certain optimizations that a container may currently do (e.g. keeping only those references to dependent objects that require cleanup on destruction)
--
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
12 years, 1 month
