[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Ales Justin (Commented) (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Ales Justin commented on CDI-18:
--------------------------------
>> Folks, introducing any hierarchy is exactly the same way broken as BDA itself. Let's just get rid of that piep!
I would say having that *piep* is not so *piep* at all, as it allows you to abstract away diff CL rules.
Who's to say which CL rules are right. ;-)
e.g. JBossAS pre-7 was doing well with that big-ball-o-mud, until that bbom become unmanageable (via JEE expansion ...).
And even if we went directly to modularity / CL, you still need a mechanism to "visit" things API way.
Since CL doesn't expose that, you need a custom layer -- here enter BDA. ;-)
> 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
> Priority: Critical
> Fix For: 1.1 (Proposed)
>
>
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Gerhard Petracek (Commented) (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Gerhard Petracek commented on CDI-18:
-------------------------------------
@mark: +1!
> 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
> Priority: Critical
> Fix For: 1.1 (Proposed)
>
>
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Pete Muir (Commented) (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Pete Muir commented on CDI-18:
------------------------------
I'm very much in favour of building this on top of modularity solutions, and not trying to create our own modularity.
> 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
> Priority: Critical
> Fix For: 1.1 (Proposed)
>
>
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Geoffrey De Smet (Commented) (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Geoffrey De Smet commented on CDI-18:
-------------------------------------
Waiting for Jigsaw is probably not a bad idea, as we might be able to piggy back on that. Global might mean something very different in a non-classpath world :)
> 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
> Priority: Critical
> Fix For: 1.1 (Proposed)
>
>
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Mark Struberg (Commented) (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Mark Struberg commented on CDI-18:
----------------------------------
I think introducing more complexity by adding weird hierarchies is completely the wrong direction!
*) how is this hierarchy being determined?
*) how should this hierarchy technically work for flat environments like OSGi?
*) what about jigsaw?
*) what about servers which unpack and re-assemble packages?
Folks, introducing any hierarchy is exactly the same way broken as BDA itself. Let's just get rid of that *piep*!
> 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
> Priority: Critical
> Fix For: 1.1 (Proposed)
>
>
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
Moving to JSR-348
by Pete Muir
Joseph, Norman, Mathieu, George, Richard, Werner, Jerome, Antoine, Mark, Siva,
We would like to move JSR-346 to the new process defined by JSR-348.
The JCP PMO have raised two points:
1) A unanimous yes vote from the EG members listed on the JCP page http://www.jcp.org/en/jsr/summary?id=346 makes it clearer we can move.
2) The JSR submission makes note of a private alias for EG members. We've not used that at any point, so we would also like a clear vote from you to remove that private alias.
Finally, I've clarified the feedback process at https://github.com/jboss/cdi/wiki#wiki-feedback - you might want to subscribe to cdi-feedback. I will forward anything relevant to cdi-dev anyway.
Pete
12 years, 5 months
Fwd: [weld-dev] @Alternative VS multiproject
by Pete Muir
Moving to cdi-dev.
Begin forwarded message:
> From: Geoffrey De Smet <ge0ffrey.spam(a)gmail.com>
> Subject: [weld-dev] @Alternative VS multiproject
> Date: 6 December 2011 15:16:07 GMT
> To: weld-dev(a)lists.jboss.org
>
> One promise of @Alternative beans is to make it easier to mock out
> things during testing.
> In practice there are some problems to make that a reality.
>
> For example, suppose we have this:
>
> - foo-database-layer.jar
> -- org/.../ProductionDatabaseSetup.class
> --- Description: connects to the database on localhost (which is only
> there on production).
> -- org/.../TestDatabaseSetup.class
> --- @Alternative
> --- extends ProductionDatabaseSetup
> --- Description: connects to an in-memory database and inserts testdata
> in it.
> - CustomerDAO
> -- @Inject DatabaseSetup databaseSetup;
> -- META-INF/beans.xml
> --- Filled with other stuff
>
> - foo-server.war
> -- WEB-INF/lib/foo-database-layer.jar
> -- WEB-INF/beans.xml
> --- Filled with other stuff
>
>
> Now, during the integrations tests of foo-server.war, we want to
> replace ProductionDatabaseSetup with TestDatabaseSetup.
>
> How?
> 1) Add a WEB-INF/beans-test.xml (just like logback-test.xml and logback.xml)
> => Does not work. It's ignored.
>
> 2) Change WEB-INF/beans.xml for the tests only.
> Duplicate everything from the original.
> Add declaration: <alternative>...TestDatabaseSetup</alternative>
> => Does not work. CustomerDAO still gets ProductionDatabaseSetup instead
> of TestDatabaseSetup.
>
> 3) Change WEB-INF/lib/foo-database-layer.jar!META-INF/beans.xml for the
> tests only.
> Duplicate everything from the original.
> Add declaration: <alternative>...TestDatabaseSetup</alternative>
> => Lots of code and tests are slow because of all the zipping and unzipping.
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
12 years, 5 months
[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Geoffrey De Smet (Commented) (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Geoffrey De Smet commented on CDI-18:
-------------------------------------
Global might be too much. Maybe we need something between LOCAL and GLOBAL, something like "DEPENDENCY_SUBTREE".
beans.xml always have dependencies to other beans.xml files, even though they aren't explicitly declared. For example: seam-remoting's beans get injected by beans from solder, so seam-remoting's beans.xml depends on solder's beans.xml (like it or not).
If you draw that dependency graph, you get a non-circular directed graph (which is a tree mostly).
The dependency subtree of any beans.xml applies on that beans.xml and all the beans.xml it directly or indirectly depends upon.
> 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
> Priority: Critical
> Fix For: 1.1 (Proposed)
>
>
> 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: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months