[JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader
by Michael Remijan (JIRA)
[ https://issues.jboss.org/browse/CDI-573?page=com.atlassian.jira.plugin.sy... ]
Michael Remijan edited comment on CDI-573 at 5/13/16 8:36 PM:
--------------------------------------------------------------
Hi Antoine. If I read these comments correctly, will CDI.getCDIProvider() visibility be back to public in Weld 3.0.0.Alpha17? Because I just tried updating to Weld 3.0.0.Alpha16 and ran into getCDIProvider() no longer being visible. Thanks!
was (Author: mjremijan):
Hi Antonie. If I read these comments correctly, will CDI.getCDIProvider() visibility be back to public in Weld 3.0.0.Alpha17? Because I just tried updating to Weld 3.0.0.Alpha16 and ran into getCDIProvider() no longer being visible. Thanks!
> Review code of CDI class to switch to ServiceLoader
> ---------------------------------------------------
>
> Key: CDI-573
> URL: https://issues.jboss.org/browse/CDI-573
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Concepts
> Affects Versions: 2.0-EDR1
> Reporter: Antoine Sabot-Durand
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0 (proposed)
>
>
> Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method.
> In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (CDI-573) Review code of CDI class to switch to ServiceLoader
by Michael Remijan (JIRA)
[ https://issues.jboss.org/browse/CDI-573?page=com.atlassian.jira.plugin.sy... ]
Michael Remijan commented on CDI-573:
-------------------------------------
Hi Antonie. If I read these comments correctly, will CDI.getCDIProvider() visibility be back to public in Weld 3.0.0.Alpha17? Because I just tried updating to Weld 3.0.0.Alpha16 and ran into getCDIProvider() no longer being visible. Thanks!
> Review code of CDI class to switch to ServiceLoader
> ---------------------------------------------------
>
> Key: CDI-573
> URL: https://issues.jboss.org/browse/CDI-573
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Concepts
> Affects Versions: 2.0-EDR1
> Reporter: Antoine Sabot-Durand
> Assignee: Antoine Sabot-Durand
> Fix For: 2.0 (proposed)
>
>
> Right now {{CDI}} seems to mimics the JDK service loader mechanism in the the private {{findAllProviders}} method.
> In order to get rid of useless code in the API and to limit compatibility issues with JDK9 and jigsaw, I think we should change this code and use Service Loader instead of doing something similar.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
Destroying @Stateless proxies obtained via CDI.current().select()
by arjan tijms
Hi,
Given a simple @Stateless bean:
@Stateless
public class Foo {
public void bar() {}
}
Then requesting an instance of this via CDI as follows:
Foo foo = CDI.current().select(Foo.class).get();
Causes a lot of leaked proxy instances (at least on Weld). Now what I guess
needs to be done is destroying the proxy, taking Antoine's answer here as a
lead: http://stackoverflow.com/questions/28767536/scope-of-stateless-bean
Only the following throws an UnsupportedOperationException (on Weld 2.3.2,
haven't tested OWB yet)
Instance<Foo> fooInstance = CDI.current().select(Foo.class);
Foo foo = fooInstance.get();
foo.bar();
fooInstance.destroy(foo);
The question is, is this how it's supposed to be done via the spec?
Implementation wise, what happens in Weld is that the CDI/EJB proxy
(com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) in the following code
doesn't hit the check for a dependent instance (comments in capitals added
by me):
public void destroy(T instance) {
Preconditions.checkNotNull(instance);
// check if this is a proxy of a normal-scoped bean
if (instance instanceof ProxyObject) {
// THIS BRANCH IS TAKEN FOR CDI/EJB PROXY
ProxyObject proxy = (ProxyObject) instance;
if (proxy.getHandler() instanceof ProxyMethodHandler) {
ProxyMethodHandler handler = (ProxyMethodHandler)
proxy.getHandler();
Bean<?> bean = handler.getBean();
Context context =
getBeanManager().getContext(bean.getScope());
if (context instanceof AlterableContext) {
AlterableContext alterableContext = (AlterableContext)
context;
// CONTEXT IS A DEPENDENTCONTEXTIMPL THAT THROWS
// UnsupportedOperationException FROM ITS DESTROY()
METHOD
alterableContext.destroy(bean);
return;
} else {
throw BeanLogger.LOG.destroyUnsupported(context);
}
}
}
// check if this is a dependent instance
CreationalContext<? super T> ctx = getCreationalContext();
if (ctx instanceof WeldCreationalContext<?>) {
WeldCreationalContext<? super T> weldCtx = cast(ctx);
// PROXY REFERENCES ARE KEPT HERE IN A
// "dependentInstances" LIST, AND WOULD BE CLEARED HERE
// BUT THIS CODE IS NEVER REACHED
weldCtx.destroyDependentInstance(instance);
}
}
Now I wonder, am I doing something wrong (according to the CDI spec), or
could this be a bug in the Weld code?
Kind regards,
Arjan Tijms
7 years, 11 months
[JBoss JIRA] (CDI-594) Instance#destroy should be linked to Instance instance which has been used for the creation
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-594?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-594:
----------------------------------
I can see the difference now. Right now, all the child {{Instance}} instances obtained through {{Instance.select()}} share the {{CreationalContext}} of the root (in most cases an injected {{Instance}}). That's why it would probably work.
The requirement to be symmetric seems reasonable but I don't get the requirement for untracked instances. For your use case it might be useful but it may break other applications where e.g. {{@PreDestroy}} callback is needed. By the way, in Weld there is an optimization where certain dependent instances are not tracked (e.g. a bean with no transitive dependency with @PreDestroy/disposal method).
In any case, CDI-519 clarifies that a bean instance to destroy must be obtained from the same {{Instance}} object.
> Instance#destroy should be linked to Instance instance which has been used for the creation
> -------------------------------------------------------------------------------------------
>
> Key: CDI-594
> URL: https://issues.jboss.org/browse/CDI-594
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Romain Manni-Bucau
>
> We suppose we have an injection of type Instance<Greeting>.
> {code}
> // adapted from javaee7-samples repo
> Instance<Greeting> select = instance.select(new AnnotationLiteral<Default>() {});
> Greeting anotherBean = select.get();
> assertThat(anotherBean, instanceOf(SimpleGreeting.class));
> select.destroy(anotherBean);
> {code}
> This version of code is working well and not ambiguous but the original one (next snippet) is currently ambiguous and I think it shouldn't even work:
> {code}
> Greeting anotherBean = instance.select(new AnnotationLiteral<Default>() {}).get();
> assertThat(anotherBean, instanceOf(SimpleGreeting.class));
> instance.destroy(anotherBean);
> {code}
> The difference is this time the destroy is called on an instance which can be different from the producing instance. For symmetry I think it should be explicitly mentionned the root instance doesn't have to support it and that the destruction should happen with the creation instance Instance. The rational behind that is to be symmetric and to allow to have untracked instances and not hold memory in a useless manner and not require ref counting which would be the alternative specification solution I think and can create issue if the code relies on Instance in a less atomic manner.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (CDI-594) Instance#destroy should be linked to Instance instance which has been used for the creation
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-594?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-594:
-----------------------------
Issue Type: Clarification (was: Epic)
> Instance#destroy should be linked to Instance instance which has been used for the creation
> -------------------------------------------------------------------------------------------
>
> Key: CDI-594
> URL: https://issues.jboss.org/browse/CDI-594
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.2.Final
> Reporter: Romain Manni-Bucau
>
> We suppose we have an injection of type Instance<Greeting>.
> {code}
> // adapted from javaee7-samples repo
> Instance<Greeting> select = instance.select(new AnnotationLiteral<Default>() {});
> Greeting anotherBean = select.get();
> assertThat(anotherBean, instanceOf(SimpleGreeting.class));
> select.destroy(anotherBean);
> {code}
> This version of code is working well and not ambiguous but the original one (next snippet) is currently ambiguous and I think it shouldn't even work:
> {code}
> Greeting anotherBean = instance.select(new AnnotationLiteral<Default>() {}).get();
> assertThat(anotherBean, instanceOf(SimpleGreeting.class));
> instance.destroy(anotherBean);
> {code}
> The difference is this time the destroy is called on an instance which can be different from the producing instance. For symmetry I think it should be explicitly mentionned the root instance doesn't have to support it and that the destruction should happen with the creation instance Instance. The rational behind that is to be symmetric and to allow to have untracked instances and not hold memory in a useless manner and not require ref counting which would be the alternative specification solution I think and can create issue if the code relies on Instance in a less atomic manner.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (CDI-594) Instance#destroy should be linked to Instance instance which has been used for the creation
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-594?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-594:
----------------------------------
I believe we should mark this issue as duplicate. See also CDI-519.
> Instance#destroy should be linked to Instance instance which has been used for the creation
> -------------------------------------------------------------------------------------------
>
> Key: CDI-594
> URL: https://issues.jboss.org/browse/CDI-594
> Project: CDI Specification Issues
> Issue Type: Epic
> Affects Versions: 1.2.Final
> Reporter: Romain Manni-Bucau
>
> We suppose we have an injection of type Instance<Greeting>.
> {code}
> // adapted from javaee7-samples repo
> Instance<Greeting> select = instance.select(new AnnotationLiteral<Default>() {});
> Greeting anotherBean = select.get();
> assertThat(anotherBean, instanceOf(SimpleGreeting.class));
> select.destroy(anotherBean);
> {code}
> This version of code is working well and not ambiguous but the original one (next snippet) is currently ambiguous and I think it shouldn't even work:
> {code}
> Greeting anotherBean = instance.select(new AnnotationLiteral<Default>() {}).get();
> assertThat(anotherBean, instanceOf(SimpleGreeting.class));
> instance.destroy(anotherBean);
> {code}
> The difference is this time the destroy is called on an instance which can be different from the producing instance. For symmetry I think it should be explicitly mentionned the root instance doesn't have to support it and that the destruction should happen with the creation instance Instance. The rational behind that is to be symmetric and to allow to have untracked instances and not hold memory in a useless manner and not require ref counting which would be the alternative specification solution I think and can create issue if the code relies on Instance in a less atomic manner.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
Canceling meeting
by Antoine Sabot-Durand
Hi guys,
I'm sorry I have to cancel today's meeting being sick with a huge head
ache.
Antoine
7 years, 11 months
F2F Doodle
by Antoine Sabot-Durand
Hi all,
To gather information regarding a possible (we still don't have a final
decision on a budget) F2F in Brno, I created a Doodle allowing each of us
to enter his/her possible weeks.
http://doodle.com/poll/snuudv2f4bhzpyxp
Please give the week were you could have 2 days available for such a
meeting. It will allow us to knows if setting the meeting is possible and
have the impossible weeks.
If we can set the meeting before EDR2 (not slot or budget) we'll try to put
one in septembre.
regards,
Antoine
7 years, 11 months
[JBoss JIRA] (CDI-420) add a bean-discovery-mode 'scoped'
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-420?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-420:
----------------------------------
http://transcripts.jboss.org/channel/irc.freenode.org/%23cdi-dev/2016/%23...
> add a bean-discovery-mode 'scoped'
> ----------------------------------
>
> Key: CDI-420
> URL: https://issues.jboss.org/browse/CDI-420
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: TBD
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> This is for some future CDI release.
> We currently only have 3 bean-discovery-modes
> * none
> * all
> * annotated
> The spec also currently says that ProcessAnnotatedType will only get fired (12.4) for
> • each Java class, interface or enum deployed in an explicit bean archive, and
> • each Java class with a bean defining annotation in an implicit bean archive.
> • each session bean
> Which means that we do not get the ProcessAnnotatedType (PAT) event for any class in an 'annotated' or 'implicit' BDA which does _not_ have a bean defining annotation.
> It might be useful to fire the ProcessAnnotatedType for all classes, but do not pick them up as Beans if they (after PAT) do not have a valid scope. Effectively doing the processing but not make them @Dependent automatically if there is no scope annotation at the end of the PAT processing.
> I'm not yet 100% sure how important this distinction is in practice. Just writing this up to not forget about the idea...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
