[JBoss JIRA] Commented: (CDI-87) Declarative control over classes including in bean archive scanning
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-87?page=com.atlassian.jira.plugin.sys... ]
Mark Struberg commented on CDI-87:
----------------------------------
To clarify what is meant (I guess):
The beans.xml syntax should get extended with explicit <exclude> and <include> tags which can be used for performance tuning of the classpath scanning.
E.g. if you have a backend project which contains a big amount of JPA entities, it would not make sense to scan this directory. So you can just add
<beans>
<scan>
<exclude>org/myproject/entities</exclude>
</scan>
</beans>
Of course we need to clarify include/exclude order and stuff. e.g.
<beans>
<scan>
<exclude>/</exclude>
<include>org/myproject/services</include>
</scan>
</beans>
We also need to clarify how the syntax of the include and exclude tags should look like: regexp or package names, etc
> Declarative control over classes including in bean archive scanning
> -------------------------------------------------------------------
>
> Key: CDI-87
> URL: https://issues.jboss.org/browse/CDI-87
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Pete Muir
> Fix For: 1.1 (Proposed)
>
>
> Weld introduced a XML syntax for this
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months
[JBoss JIRA] Commented: (CDI-136) Assumption all @Stateful beans should be passivation capable
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-136?page=com.atlassian.jira.plugin.sy... ]
Pete Muir commented on CDI-136:
-------------------------------
I've spoken to the EE CTS team at Oracle about this (how we handle issues filed against the TCK that are correct for this revision of the spec but being changed in later revisions). Their advice is to not exclude tests if they are correct for the version of the CDI spec which they are verifying. Therefore I don't think we should exclude those tests from CDI TCK 1.0.x.
> Assumption all @Stateful beans should be passivation capable
> ------------------------------------------------------------
>
> Key: CDI-136
> URL: https://issues.jboss.org/browse/CDI-136
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Beans, Java EE integration
> Affects Versions: 1.0
> Reporter: David Blevins
> Assignee: Pete Muir
> Fix For: 1.1 (Confirmed)
>
>
> Stateful session beans in transactions can't be passivated and shouldn't have passivation requirements either, like request scope.
> Stateful beans can be any scope. They are the Bertie Bott's Every Flavor Beans of EJB. It's too big of a brush to say that passivation is always required. That's the part we need to fix.
> Stateful session beans that do passivate are pretty rare. They should be assumed to be @NormalScope unless otherwise specified.
> The user should be able to say if they want passivation validation on their stateful bean and dependencies.
> We should at a minimum change the related language of the spec to be "For every bean which declares a passivating scope, and for every stateful session bean ***that requires passivation***, " and discuss how to determine that an SFSB requires passivation.
> From the EJB perspective this has always been a container detail, but we could have a rule in CDI that states the checks are not enforced unless the bean class explicitly implements java.io.Serializable. Alternatively we could make a generic @PassivationScoped annotation for other architectures that have flexible scopes and support passivation concepts.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 8 months