[
https://issues.jboss.org/browse/WELD-778?page=com.atlassian.jira.plugin.s...
]
Mark Struberg commented on WELD-778:
------------------------------------
Pete what I meant is that the EE doesn't specify any classloading nor class handling
at all. Thus the BDA definition must not rely on such things. E.g. in some OSGi
environments, you don't get your hands on any JAR at all. Instead all those
'physical' parts are shielded from you and you just get one big fat classpath. Not
sure how the BDA definition should ever work for those situations.
And yes, the ClassLoading -> CDI is somehow circular. I know this is not a failure of
the CDI spec, but we still must take care of it
As for 'Application': JSR-316 both names a 'Web Application' (Servlet3.0
references) and a 'Java EE application'.
The problem is that the JSR-299 section 2.4.1 _explicitly_ says the following:
The @RequestScoped, @ApplicationScoped and @SessionScoped annotations
defined in Section 6.7,
“Context management for built-in scopes” represent the standard scopes defined by the
Java Servlets specification.
And the Java Servlets Specification _only_ mentions the Web Application.
See what I mean? Sorry for not being clear enough in my previous comment, but I'm also
juggling through hundreds of spec pages which almost drives me crazy ;)
Weld must be able to support extension discovery in the modules of an
multi-module application (EAR)
----------------------------------------------------------------------------------------------------
Key: WELD-778
URL:
https://issues.jboss.org/browse/WELD-778
Project: Weld
Issue Type: Feature Request
Components: Bootstrap and Metamodel API
Affects Versions: 1.1.0.Beta2
Reporter: Marius Bogoevici
Fix For: TBC
Currently, only extensions which are visible to the entire application (i.e. all modules)
are installed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira