Status of PR296
by Antoine Sabot-Durand
Hi,
PR296 (CDI-30) is nearly ready IMO. The last big agreement is about
ManageableContext inheriting AlterableContext as it was discussed during
last meeting.
@John will you have time to discuss this point and rework on it before the
end of the week?
Antoine
8 years, 5 months
Last PR to close before EDR2
by Antoine Sabot-Durand
Hi all,
PR283, 290, & 295 are ready to be merge from my POV. Please do a last
review and add +1 if you agree for this merge.
Antoine
8 years, 5 months
[JBoss JIRA] (CDI-414) Support for "self" injection or intercepted self invocation
by Lucas Ventura Carro (JIRA)
[ https://issues.jboss.org/browse/CDI-414?page=com.atlassian.jira.plugin.sy... ]
Lucas Ventura Carro commented on CDI-414:
-----------------------------------------
{{Instance}} solution from [~paulie-paulie] is memory-leak prone: the produced instances should be destroyed after being used.
Is there any plan to introduce the self-interception in next CDI release, in any way?
> Support for "self" injection or intercepted self invocation
> -----------------------------------------------------------
>
> Key: CDI-414
> URL: https://issues.jboss.org/browse/CDI-414
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Resolution
> Reporter: arjan tijms
> Fix For: 2.0 (discussion)
>
>
> Many features of CDI and EJB work by means of a proxy that intercepts calls and adds 'aspects'. In Java it's however not possible to decorate the {{this}} pointer, so methods called on the same bean instance from within a method in the bean do not get their 'aspects' applied.
> This is a well known limitation, but in EJB it's possible to work around this by injecting a bean into itself. E.g.
> {code}
> @Stateless
> public class Foo {
> @EJB
> private Foo self;
> // ...
> }
> {code}
> Also see http://adam-bien.com/roller/abien/entry/how_to_self_invoke_ejb
> Unfortunately using CDI and {{@Inject}} this doesn't work. Weld for instance fails the deployment and logs:
> {noformat}
> WELD-001443 Pseudo scoped bean has circular dependencies.
> {noformat}
> See also: http://adam-bien.com/roller/abien/entry/inject_vs_ejb
> Although there are workarounds, it would be great if {{@Inject}} in combination with CDI could support self injection as well.
> With that projects migrating from {{@EJB}} to {{@Inject}} can do so more easily and the capability can be convenient for new projects as well (e.g. calling two separate {{@Transactional}} methods from a single method without being required to create a new bean).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
CDI-616 Injection point declared as transient is not useful
by Stephan Knitelius
Hi,
I frequently encounter injections marked transient in client projects. I
really think it would be of great help if we where to define Error/Warning
when injection fields are marked transient.
As Mark pointed out there may be a valid use cases for non normal-scoped
bean injections to be made transient.
My suggestion is:
- ERROR - when normal scoped injects are marked transient.
- WARNING - when non-normal scoped injects are marked transient.
Looking forward to your feedback.
Stephan
8 years, 6 months
How will attend tomorrow's meeting on IRC
by Antoine Sabot-Durand
Hi all,
As it's summer time, I'm checking who'll be availabale for our tomorrow's
meeting (video's meeting being canceled). Thx to answer.
Antoine
8 years, 6 months
Hierarchy of ManageableContext and Context
by John D. Ament
All,
I'm starting a discussion thread outside of the PR to avoid folks on the EG
not receiving github notifications. I want to drive to get the opinions of
the broader EG and use this as feedback on whether or not we change the
hierarchy.
I've been against having ManageableContext (MC) extend
Context/AlterableContext (AC). There's a few reasons. First, semantically
I can register a context, but I shouldn't be able to register a MC. That
means from an inheritance standpoint MC does not pass the is-a check on
AC. MC may be a composition style, or nothing at all since it may not be
associated to any specific thread in the future. While we can put in spec
verbiage and exceptions to cover the cases where someone does implement MC
and try to register it, realistically if it's there as a compilation time
option, I shouldn't get an error if it passes.
I can agree that the bulk of the methods on MC should match AC. That's
where I introduced a new base class for the two and had MC extend that.
The base class provided no behavior, just method signatures. The second
key thing for me is in this area. AC is more like a definition, where as
MC is a running instance of that definition. Since these are different, it
shows that MC doesn't inherit the use-case of the parent AC.
Third issue I have with extending is that AC is meant to be implemented by
developers to create custom contexts. Developers aren't intended to
implement MC. The container should provide these instances, since they are
intended only for built in contexts. We allow developers who implement AC
to control their activation, as a result we've already provided a means to
disassociate a custom AC from any thread.
I want to get others opinions on whether these reasons make sense and if
they guide to the same conclusion about not extending AC. For what its
worth, I've shown these classes to some of my own developers to get their
feedback, who have had to do things like quartz integration or responding
to netty requests and activate contexts. The concerns I raise are based on
questions they've asked me.
John
8 years, 6 months
