[JBoss JIRA] (CDI-300) The entire RAR recognized as one bean archive
by Martin Kouba (JIRA)
Martin Kouba created CDI-300:
--------------------------------
Summary: The entire RAR recognized as one bean archive
Key: CDI-300
URL: https://issues.jboss.org/browse/CDI-300
Project: CDI Specification Issues
Issue Type: Clarification
Reporter: Martin Kouba
The spec states:
{quote}
A library jar, EJB jar, application client jar or *rar archive* is a bean archive if it has a file named beans.xml in the META-INF directory.
...
In an application deployed as an ear, the container searches every bean archive bundled with or referenced by the ear, including bean archives bundled with or referenced by wars and EJB jars contained in the ear. The bean archives might be library jars, EJB jars, rars or war WEB-INF/classes directories.
{quote}
I wonder if the intention wasn't to support *jars packaged inside RAR* instead of the whole RAR. Though I'm not sure about RAR packaging structure.
--
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, 5 months
Re: [cdi-dev] [Vote] @ApplicationScoped and visibility
by Mark Struberg
weld behaves that way since ever. and in all the 2 years since CDI is final there is no version available where it worked like described in 1a. facts have nothing to do with fair or not...
------------------------------
Jozef Hartinger schrieb am Mo., 26. Nov 2012 09:21 PST:
>On 11/26/2012 03:29 PM, Mark Struberg wrote:
>> All current containers (EE and standalone, namely Weld, Glassfish, OpenWebBeans, JBossAS 6 and 7, WebSphere, TomEE) implement 1(b) as shown via the small example available at [1]
>> Thus taking 1.a would introduce heavy backward compatibility issues.
>It's not fair to say that all those containers implement 1(b). A bug in
>Weld (which also affects the application servers using it) causes Weld
>to unintentionally behave similarly to 1(b) in certain scenarios. This
>is far from fully implementing all the consequences of 1(b). Your
>testcase demonstrates one such scenario.
>
>>
>> Therefore I VOTE for 1.b
>>
>>
>> As for question 2 I VOTE for 2.b as the 1-per-ear Scope already exists twice in the form of javax.ejb.Singleton and javax.inject.Singleton.
>>
>>
>> LieGrue,
>> strub
>>
>>
>> [1] https://github.com/struberg/cdi_eartest
>>
>>
>>
>> ----- Original Message -----
>> From: Pete Muir <pmuir(a)redhat.com>
>> To: cdi-dev(a)lists.jboss.org
>> Cc:
>> Sent: Monday, November 26, 2012 2:44 PM
>> Subject: [cdi-dev] [Vote] @ApplicationScoped and visibility
>>
>> CDI EG members,
>>
>> Please vote on the following two issues by indicating whether you prefer either
>> option (a) or (b) to both questions (1) and (2). Please vote asap, voting closes
>> as soon as I have a complete set of votes from the EG or at COB (Eastern) on
>> 30th Nov, whichever happens sooner :-)
>>
>> Question 1, Visibility
>> ---------------------------
>>
>> The CDI 1.0 specification states that only beans whose bean class is accessible
>> (using standard classloader visibility rules) can be injected into another bean.
>> For example, if you have a bean A in WAR, assuming standard Java EE classloader
>> structure, it wouldn't be available for injection in bean B, in an EJB
>> modiule. This generally makes sense, as the type is not visible either.
>>
>> CDI also offers two options to replace bean implementations transparently,
>> without explicitly selecting that implementation (either by type or using a
>> qualifier) - alternatives and specialization.
>>
>>
>> First, let's consider specialization. For example, if bean B, from the
>> example above, is specialized by bean S in the WAR, and bean C in the same EJB
>> module as B injects a type B, then what should be injected (if anything). The
>> CDI 1.0 specification addresses this issue by disabling any bean which has been
>> specialized across the entire application. Therefore, according to CDI 1.0, this
>> would result in an deployment problem (as there would be an unsatisfied
>> injection point).
>>
>> Alternatives are addressed a little differently in CDI 1.0. For example, if bean
>> B has an alternative A packaged in the WAR, then if A is selected in the war
>> only, then if bean C in the same EJB module as B injects a type B, it would be
>> injected with C. However, if A is selected for the EJB module as well, then the
>> deployment should fail as beans.xml of the EJB module references S which it
>> cannot see. Note that we have also added global visibility for alternatives in
>> CDI 1.1, which may need revising based on what is decided here.
>>
>> The EG has debated two options.
>>
>> (a) maintain the status quo, as described by the CDI 1.0 spec
>> (b) take an approach where visibility is isolated according to the calling
>> context. Thus, if a call originates via the WAR, then specialization and enabled
>> alternatives in the WAR are visible to any bean which is called in that stack.
>>
>> Approximately, Weld takes approach (a), and OWB takes approach (b), so which
>> approach is more backwards compatible here is debatable.
>>
>>
>> Question 2, @ApplicationScoped
>> ---------------------------------------------
>>
>> CDI implementations have not consistently shared @ApplicationScoped beans across
>> all modules of an EAR. Weld, and app servers built on Weld (those that we have
>> surveyed include JBoss AS, GlassFish, WebLogic) have shared application scoped
>> beans across the EAR. OWB isolates @ApplicationScoped beans to the calling
>> context of the WAR, however applications servers built on OWB have shared beans
>> across all modules of an EAR (this is certainly true of WebSphere, and I believe
>> it is true of TomEE).
>>
>> The EG has debated two options.
>>
>> (a) require @ApplicationScoped beans to be shared across all modules of an EAR
>> (b) take an approach where @ApplicationScoped beans are isolated to the calling
>> context
>>
>> Whichever approach is taken, the EG is agreed that a scope that addresses the
>> other option should be introduced.
>>
>> So, please indicated which options you favour:
>>
>> Question 1: (a) OR (b)
>> Question 2: (a) OR (b)
>>
>> Thanks,
>>
>> Pete
>>
>>
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
11 years, 5 months
[JBoss JIRA] (CDI-302) Issues with interceptor and decorator ordering
by Pete Muir (JIRA)
Pete Muir created CDI-302:
-----------------------------
Summary: Issues with interceptor and decorator ordering
Key: CDI-302
URL: https://issues.jboss.org/browse/CDI-302
Project: CDI Specification Issues
Issue Type: Bug
Reporter: Jozef Hartinger
1.) If a library globally enables an alternative/interceptor/decorator it is not possible to disable it in other libraries without repackaging the library / other libraries.
2.) In the legacy mode (enablement for bean archive), the priority of an alternative/interceptor/decorator is undefined (other than the first one in the list)
--
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, 5 months
[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Martin Kouba commented on CDI-18:
---------------------------------
[~struberg] retested with Weld 1.1.5 (AS71) and 2.0.0.Aplha4: alternatives are selected per bean archive, so that alternative selected in WEB-INF/beans.xml is not selected (not available for injection) for any WEB-INF/lib bean archive (unless also selected in its beans.xml :-)
> 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
11 years, 5 months
[JBoss JIRA] (CDI-292) Drop ProcessModule.getAnnotatedTypes()
by Jozef Hartinger (JIRA)
Jozef Hartinger created CDI-292:
-----------------------------------
Summary: Drop ProcessModule.getAnnotatedTypes()
Key: CDI-292
URL: https://issues.jboss.org/browse/CDI-292
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Portable Extensions
Affects Versions: 1.1.PFD
Reporter: Jozef Hartinger
Assignee: Pete Muir
Fix For: 1.1 (Proposed)
With @WithAnnotations in place it is now possible for extensions to indicate with fine granularity which container lifecycle events it is interested in and thus not to harm performance that much if the CDI implementation is efficient.
Therefore, I don't like the ProcessModule.getAnnotatedTypes() method because:
1.) There is no granularity. If extensions start to use it inefficiently it will always harm performance heavily.
2.) I am not convinced this method is needed. It was not present in CDI 1.0. The only benefit of the method is that it allows for an extension to get an idea where a given AnnotatedType is comming from. There are other more efficient ways of exposing the same information. If we really need to do this we should probably introduce an abstraction over a bean archive (e.g. a Module object) and add a getModule() method to ProcessAnnotatedType.
--
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, 5 months
[JBoss JIRA] (CDI-295) ProcessModule.getAlternatives() should return List instead of Set
by Jozef Hartinger (JIRA)
Jozef Hartinger created CDI-295:
-----------------------------------
Summary: ProcessModule.getAlternatives() should return List instead of Set
Key: CDI-295
URL: https://issues.jboss.org/browse/CDI-295
Project: CDI Specification Issues
Issue Type: Bug
Components: Beans
Affects Versions: 1.1.PRD
Reporter: Jozef Hartinger
Assignee: Pete Muir
Fix For: 1.1 (Proposed)
CDI-18 defines ordering of alternatives. In order to preserve the order ProcessModule.getAlternatives() should return List<Class<?>> instead of Set<Class<?>>.
--
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, 5 months
[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:
------------------------------
I believe that the proposed solution addresses the cases DefaultBean addressed, and actually does it better. It allows default enablement of alternatives across the entire app, and allows that to be overridden (globally) or disabled for a particular module or jar.
> 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
11 years, 5 months
[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:
----------------------------------
{quote}
Alternatives are enabled as required by the spec (per bean archive) in JBoss AS
{quote}
Bean Archive is defined as each JAR being an own Bean Archive in CDI-1.0. As far as my tests showed an enabled alternative in WEB-INF/beans.xml is available in all jars in WEB-INF/lib/*.jar. I agree that this makes more sense than having each jar being an own BDA - but it's clearly against CDI-1.0 if implemented that way.
Can you verify this please? I tested this with JBossAS-7.0.1 and 7.1.0 back then afair.
> 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
11 years, 5 months
[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:
----------------------------------
There are quite some options. E.g. disabling BDA if a single beans.xml with version="1.1" gets detected. This got used in JPA, JSF, etc. So really nothing to worry about.
Btw, even lots of JBoss folks actively involved in real world projects have acknowledged that BDA is utter broken. See the discussion and solution attempt around JBoss Solder DefaultBean...
Add to that that only a minority EE container currently implements the strict BDA rules which got defined in CDI-1.0. Quite some of them treat all WEB-INF/lib/*.jar + the WEB-INF/classes as a single BDA it seems. JBossAS7 is amongst them as far as a small sample application showed.
> 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
11 years, 5 months