[JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-580:
-----------------------------------
BeanInstanceProducer which is stripped of almost everything a bean does (besides interceptors/decorators)?
> Allow interceptors and decorators to be applied to the return value of a producer method
> ----------------------------------------------------------------------------------------
>
> Key: CDI-580
> URL: https://issues.jboss.org/browse/CDI-580
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 2.0-EDR1
> Reporter: Mark Struberg
>
> Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods.
> if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object.
> We should explore ways to allow this somehow.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (CDI-580) Allow interceptors and decorators to be applied to the return value of a producer method
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-580?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-580:
------------------------------------------
We discussed this feature during last F2F meeting. My suggestion was to introduce a {{BeanInstanceBuilder}} interface to generate an unmanaged instance for a given {{AnnotatedType}}.
This is inspired by the existing {{UnManaged}} helper class for injecting and calling lifecycle callbacks unmanaged instances.
{{UnManaged}} only uses a class (containing @Inject, @PostConstruct and @Presdetroy annotations) to create instances, {{BeanInstanceBuilder}} would use an {{AnnotatedType}} allowing the use of a synthetic {{AnnotatedType}} containing annotations added by the user like interceptor bindings or {{@Inject}} mentions not present in the original class.
We should forbid or ignore other annotations (scope, qualifier on class
This would allow applying interceptor on a produced class but also interceptor on method in the produced class. And finally it could also be used to have interceptor on custom beans.
Code would look like this
{code}
public class MyAdvancedProducerBean {
public BeanInstanceProducer<MyClass> bip = Builders.beanInstanceProducer();
@Produces
@RequestScoped
public MyClass produceTransactionalMyClass() {
AnnotatedTypeBuilder<MyClass> atb = Builders.annotatedType(Myclass.class)
.read(MyClass.class)
.addToType(new TransactionalLiteral());
return bip.read(atb.build()).inject().postConstruct().intercept().decorate().get(); // injection, callbacks and proxies creation
}
public void disposeMyClass (@Disposes Myclass td) {
bip.dispose(td);
}
}
{code}
The important point is that BeanInstanceProducer is an interface so implementation will use specific proxy feature of Weld or OWB.
wdyt?
> Allow interceptors and decorators to be applied to the return value of a producer method
> ----------------------------------------------------------------------------------------
>
> Key: CDI-580
> URL: https://issues.jboss.org/browse/CDI-580
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 2.0-EDR1
> Reporter: Mark Struberg
>
> Currently the spec explicitly disallows to apply interceptors and decorators to contextual instances created by producer fields and producer methods.
> if you add an Interceptor annotation to a producer method then only the invocation of the producermethod gets intercepted. The created Contextual Instance will remain a plain object.
> We should explore ways to allow this somehow.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
test weld 3.0.0-SNAPSHOT with wildfly 9.0
by baochen su
hi all,
I want to test weld-core 3.0.0-SNAPSHOT with wildfly-9.0.2.Final, but
because no probe directory exists in
modules/system/layers/base/org/jboss/weld, so mvn package -Pupdate-jboss-as
... failed.
I have modify jboss-as/pom.xml and add those lines just before <delete>:
<mkdir
dir="${module.dir}/core/main"/>
<mkdir
dir="${module.dir}/spi/main"/>
<mkdir
dir="${module.dir}/api/main"/>
<mkdir
dir="${module.dir}/probe/main"/>
this works fine, but one problem remain: file "module.xml" for probe not
provided by wildfly, so how can I find or create suitable module.xml for
probe? Or, any patch needed for the missing module.xml file to pom.xml?
Thanks in advance!
--
View this message in context: http://cdi-development-mailing-list.1064426.n5.nabble.com/test-weld-3-0-0...
Sent from the CDI Development mailing list mailing list archive at Nabble.com.
8 years, 2 months
test weld 3.0.0-SNAPSHOT with wildfly-9.0.2?
by subaochen
hi all,
I want to test weld-core 3.0.0-SNAPSHOT with wildfly-9.0.2.Final, but because no probe directory exists in modules/system/layers/base/org/jboss/weld, so mvn package -Pupdate-jboss-as ... failed.
I have modify jboss-as/pom.xml and add those lines just before <delete>:
<mkdir dir="${module.dir}/core/main"/>
<mkdir dir="${module.dir}/spi/main"/>
<mkdir dir="${module.dir}/api/main"/>
<mkdir dir="${module.dir}/probe/main"/>
this works fine, but one problem remain: file "module.xml" for probe not provided by wildfly, so how can I find or create suitable module.xml for probe? Or, any patch needed for the missing module.xml file to pom.xml?
Thanks in advance!
--
Best regards,
宿宝臣
-----------------------------------------------------------
我的知识库：http://dz.sdut.edu.cn/wiki
我的博客：http://dz.sdut.edu.cn/blog/subaochen
我的微博：http://weibo.com/subaochen
我的微信：baochensu
8 years, 2 months
[JBoss JIRA] (CDI-577) Non-Dependent scope specified on Decorator
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-577?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-577:
---------------------------------
https://github.com/cdi-spec/cdi/pull/275
> Non-Dependent scope specified on Decorator
> ------------------------------------------
>
> Key: CDI-577
> URL: https://issues.jboss.org/browse/CDI-577
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Decorators
> Affects Versions: 1.0, 1.2.Final
> Reporter: Emily Jiang
> Priority: Minor
> Fix For: 2.0 (proposed)
>
>
> In CDI specification, there lacks a clarification about what will happen if a scope other than Dependent specified on Decorators/Interceptors.
> At the moment, if the RequestScoped is specified on a decorator, Weld throws NPE. I talked to Martin. Martin logged https://issues.jboss.org/browse/WELD-2085 to fix this. It is better for the spec to clearly define the behaviour.
> Obviously, the lifecycle of interceptors/decorators are dependent on the bean instance they decorate. The spec should specify clearly what should happen if a scope other than Dependent is specified on decorators/interceptors. How about add the following on the spec:
> If an interceptor or decorator specifies any scope other than Dependent, the container automatically detects the problem and threats as a definition error.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes with non-private final methods
by Werner Keil
+1
Werner
On Tue, Feb 9, 2016 at 6:43 PM, <cdi-dev-request(a)lists.jboss.org> wrote:
> Send cdi-dev mailing list submissions to
> cdi-dev(a)lists.jboss.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> or, via email, send a message with subject or body 'help' to
> cdi-dev-request(a)lists.jboss.org
>
> You can reach the person managing the list at
> cdi-dev-owner(a)lists.jboss.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cdi-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: [Vote] for CDI-527 / PR 271 allow proxying of classes
> with non-private final methods (Thomas Andraschko)
> 2. Re: [Vote] for CDI-527 / PR 271 allow proxying of classes
> with non-private final methods (Jens Schumann)
> 3. Re: [Vote] for CDI-527 / PR 271 allow proxying of classes
> with non-private final methods (Emily Jiang)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 9 Feb 2016 18:08:53 +0100
> From: Thomas Andraschko <andraschko.thomas(a)gmail.com>
> Subject: Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of
> classes with non-private final methods
> To: Mark Struberg <struberg(a)yahoo.de>
> Cc: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <CAAuOd=W2s4S1-ke+vnyGOa-mrCBY9aU9bjuLZh1=
> cFDmwZ6ouA(a)mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> +1
>
> not sure if the PR is the best way but as mark already said, it would solve
> a problem in a portable way which exists in some real world applications
>
> 2016-02-09 18:00 GMT+01:00 Mark Struberg <struberg(a)yahoo.de>:
>
> > +1
> >
> > This is a real world problem and it would imo be a pitty to not have it
> in
> > the spec in a portable way.
> >
> > LieGrue,
> > strub
> >
> >
> > > Am 09.02.2016 um 17:36 schrieb Antoine Sabot-Durand <
> > antoine(a)sabot-durand.net>:
> > >
> > > Hi all,
> > >
> > > There have been a lot of discussion around CDI-527 in the last weeks:
> > > https://issues.jboss.org/browse/CDI-527
> > >
> > > Mark proposed a PR:
> > > https://github.com/cdi-spec/cdi/pull/271
> > >
> > > But we don't agree on adding this feature to the spec.
> > > This vote is to decide if we should add this feature at the spec level
> > now, or not.
> > > Should we vote this feature down, that won't mean it will be completely
> > dropped: it could be implemented as non portable feature in both Spec or
> > even be included as experimental feature in the spec (in annexes) as
> > describe in the PR comments
> > > Vote starts now, only vote from EG members are binding (but you can
> give
> > your opinion if not part of the EG) and will last 72 hours.
> > >
> > > You vote with the following values:
> > > +1 : I'm favorable for adding this feature in the spec
> > > -1 : I'm against adding this feature in the spec
> > > 0 : I don't care
> > >
> > > Thank you for your attention and your vote.
> > >
> > > Antoine Sabot-Durand
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >
> > > Note that for all code provided on this list, the provider licenses the
> > code under the Apache License, Version 2 (
> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual property rights inherent in such information.
> >
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
> > code under the Apache License, Version 2 (
> > http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> > provided on this list, the provider waives all patent and other
> > intellectual property rights inherent in such information.
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20160209/b815dcb8/at...
>
> ------------------------------
>
> Message: 2
> Date: Tue, 9 Feb 2016 17:13:50 +0000
> From: Jens Schumann <jens.schumann(a)openknowledge.de>
> Subject: Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of
> classes with non-private final methods
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID: <D2DFD4AB.60744%jens.schumann(a)openknowledge.de>
> Content-Type: text/plain; charset="us-ascii"
>
> +1
>
> (even though I can live with a portable alternative approach to the
> current PR)
>
> So far I did not express my support for this PR even though I promised to
> do so. Unable to proxy those classes is a major issue to me while migrating
> old software to a newer environment.
>
> As soon as you deal with 5 to 10+ years old software and try to migrate
> your large application step by step you will encounter framework base
> classes with (protected) final methods. CDI, @Inject and interceptors help
> a lot to cleanup the old stuff, however I have to extend (currently
> unproxyable) framework base classes to do so. Example: I have to extend
> AbstractFrameworkXyzAction with public and/ or protected final methods to
> implement use case logic, and the derived classes should be CDI beans.
>
> On the other hand - changing the old jar's is not an option either.
>
> With this feature I can stop copying the modified base classes to my local
> archive (mostly .war) in order to override the old classes.
>
> Jens
>
>
>
>
> Von: <cdi-dev-bounces(a)lists.jboss.org<mailto:
> cdi-dev-bounces(a)lists.jboss.org>> on behalf of Antoine Sabot-Durand <
> antoine(a)sabot-durand.net<mailto:antoine@sabot-durand.net>>
> Datum: Tuesday 9 February 2016 17:36
> An: CDI-Dev <cdi-dev(a)lists.jboss.org<mailto:cdi-dev@lists.jboss.org>>
> Betreff: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes
> with non-private final methods
>
> Hi all,
>
> There have been a lot of discussion around CDI-527 in the last weeks:
> https://issues.jboss.org/browse/CDI-527
>
> Mark proposed a PR:
> https://github.com/cdi-spec/cdi/pull/271
>
> But we don't agree on adding this feature to the spec.
> This vote is to decide if we should add this feature at the spec level
> now, or not.
> Should we vote this feature down, that won't mean it will be completely
> dropped: it could be implemented as non portable feature in both Spec or
> even be included as experimental feature in the spec (in annexes) as
> describe in the PR comments
> Vote starts now, only vote from EG members are binding (but you can give
> your opinion if not part of the EG) and will last 72 hours.
>
> You vote with the following values:
> +1 : I'm favorable for adding this feature in the spec
> -1 : I'm against adding this feature in the spec
> 0 : I don't care
>
> Thank you for your attention and your vote.
>
> Antoine Sabot-Durand
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20160209/3cafc912/at...
>
> ------------------------------
>
> Message: 3
> Date: Tue, 9 Feb 2016 17:42:59 +0000
> From: Emily Jiang <EMIJIANG(a)uk.ibm.com>
> Subject: Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of
> classes with non-private final methods
> To: cdi-dev <cdi-dev(a)lists.jboss.org>
> Message-ID:
> <201602091743.u19Hh60g030078(a)d06av08.portsmouth.uk.ibm.com>
> Content-Type: text/plain; charset="us-ascii"
>
> +1.
> This is a really useful feature as more and more customers will move
> forward to Java8 and might hit this problem.
>
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone: +44 (0)1962 816278 Internal: 246278
>
> Email: emijiang(a)uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From: Jens Schumann <jens.schumann(a)openknowledge.de>
> To: cdi-dev <cdi-dev(a)lists.jboss.org>,
> Date: 09/02/2016 17:15
> Subject: Re: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying
> of classes with non-private final methods
> Sent by: cdi-dev-bounces(a)lists.jboss.org
>
>
>
> +1
>
> (even though I can live with a portable alternative approach to the
> current PR)
>
> So far I did not express my support for this PR even though I promised to
> do so. Unable to proxy those classes is a major issue to me while
> migrating old software to a newer environment.
>
> As soon as you deal with 5 to 10+ years old software and try to migrate
> your large application step by step you will encounter framework base
> classes with (protected) final methods. CDI, @Inject and interceptors help
> a lot to cleanup the old stuff, however I have to extend (currently
> unproxyable) framework base classes to do so. Example: I have to extend
> AbstractFrameworkXyzAction with public and/ or protected final methods to
> implement use case logic, and the derived classes should be CDI beans.
>
> On the other hand - changing the old jar's is not an option either.
>
> With this feature I can stop copying the modified base classes to my local
> archive (mostly .war) in order to override the old classes.
>
> Jens
>
>
>
>
> Von: <cdi-dev-bounces(a)lists.jboss.org> on behalf of Antoine Sabot-Durand <
> antoine(a)sabot-durand.net>
> Datum: Tuesday 9 February 2016 17:36
> An: CDI-Dev <cdi-dev(a)lists.jboss.org>
> Betreff: [cdi-dev] [Vote] for CDI-527 / PR 271 allow proxying of classes
> with non-private final methods
>
> Hi all,
>
> There have been a lot of discussion around CDI-527 in the last weeks:
> https://issues.jboss.org/browse/CDI-527
>
> Mark proposed a PR:
> https://github.com/cdi-spec/cdi/pull/271
>
> But we don't agree on adding this feature to the spec.
> This vote is to decide if we should add this feature at the spec level
> now, or not.
> Should we vote this feature down, that won't mean it will be completely
> dropped: it could be implemented as non portable feature in both Spec or
> even be included as experimental feature in the spec (in annexes) as
> describe in the PR comments
> Vote starts now, only vote from EG members are binding (but you can give
> your opinion if not part of the EG) and will last 72 hours.
>
> You vote with the following values:
> +1 : I'm favorable for adding this feature in the spec
> -1 : I'm against adding this feature in the spec
> 0 : I don't care
>
> Thank you for your attention and your vote.
>
> Antoine Sabot-Durand_______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/cdi-dev/attachments/20160209/4fcc1e81/at...
>
> ------------------------------
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (
> http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
> provided on this list, the provider waives all patent and other
> intellectual property rights inherent in such information.
>
> End of cdi-dev Digest, Vol 63, Issue 7
> **************************************
>
8 years, 2 months
[JBoss JIRA] (CDI-582) Configurable concurrency control for CDI
by Stephan Knitelius (JIRA)
Stephan Knitelius created CDI-582:
-------------------------------------
Summary: Configurable concurrency control for CDI
Key: CDI-582
URL: https://issues.jboss.org/browse/CDI-582
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Contexts
Affects Versions: 2.0-EDR1
Reporter: Stephan Knitelius
Currently the spec only defines, a non-configurable, concurrency control mechanism for conversation scope. All other build-in scopes remain unprotected, relaying on the developer.
It would be useful to introduce EJB Singleton style concurrency control for CDI scopes.
Allowing the developer to configure the concurrency behavior of ConversationScoped beans, and defining concurrency control for the other build-in scopes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (CDI-581) possible chicken-egg problem with ProcessBeanAttributes#veto and specialization
by Mark Struberg (JIRA)
Mark Struberg created CDI-581:
---------------------------------
Summary: possible chicken-egg problem with ProcessBeanAttributes#veto and specialization
Key: CDI-581
URL: https://issues.jboss.org/browse/CDI-581
Project: CDI Specification Issues
Issue Type: Bug
Affects Versions: 1.2.Final
Reporter: Mark Struberg
Currently section 12 describes that ProcessBeanAttributes only should get fired for 'enabed beans'.
{quote}
12.4.3. Bean discovery
* if the class is an enabled bean, interceptor or decorator, fire an event of type ProcessBeanAttributes, as defined in ProcessBeanAttributes event,
{quote}
But if you have class B extends A and B is @Specializes then you don't know which PBA to fire. Because B could get vetoed in ProcessBeanAttributes. And then while you fire PBA you implicitly change the list of enabled beans. This gets even more complicated by the ability of ProcessBeanAttributes to change the isAlternative bit and even the types of the whole bean.
I think this might be a left-over of the split between Bean and BeanAttributes. The ProcessBeanAttributes is right in the middle between ProcessAnnotatedType and ProcessBean.
* ProcessBean die _not_ have a veto(), PAT does have it.
* PAT gets fired for all discovered classes, ProcessBean only for enabled ones.
I think the wording 'if the class is an enabled *bean*' is also misleading. We do _not_ have a bean at this early stage! We only have an AnnotatedType. Maybe it should read ''if the class is a not vetoed AnnotatedType'?
I'm not sure if there is a way the current wording could get cleanly implemented. I just stumbled across this because we did _not_ fire a PBA for a class because the @Specialized bean got vetoed away.
The same chicken-egg problem might apply to
{quote}
11.5.9. ProcessBeanAttributes event
The container must fire an event for each bean, interceptor or decorator deployed in a bean
archive, before registering the Bean object."
{quote}
Reads "for every bean". But we don't have any beans yet. We can only make the Bean<T> after the BeanAttributes get returned from PBA. Otherwise changing the bean attributes would have no effect on the Bean, right?
What could work is roughly:
* fire PAT for all detected classes
* remove vetoed ones
* fire PBA for all AnnotatedTypes
* remove vetoed one
* calculate disabled BeanAttributes (@Specializes rule for classes)
* produce Beans
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
