[JBoss JIRA] (CDI-666) simplify context implementation
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-666?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-666:
--------------------------------
+1 to doing something like this. This is effectively every context implementation I've seen.
> simplify context implementation
> -------------------------------
>
> Key: CDI-666
> URL: https://issues.jboss.org/browse/CDI-666
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
>
> Today implementing a context leads to implementing Context or AlterableContext interface.
> Then for Thread Local related scopes it leads to handle activation, deactivation (thread local set/remove) and delegation of the context to a sub context (implementing or not Context interface). Finally it requires a destroyEnd() method destroying all instances.
> It also requires the instance tracking and instantiation correctly (with lock or not depending the usage).
> Here is a schematic implementation (easier than previous paragraph to read ;)):
> {code}
> public class CommandContext implements AlterableContext {
> private final ThreadLocal<Delegate> delegate = new ThreadLocal<>();
> @Override
> public Class<? extends Annotation> getScope() {
> return CommandScoped.class;
> }
> @Override
> public <T> T get(final Contextual<T> component, final CreationalContext<T> creationalContext) {
> return delegate.get().get(component, creationalContext);
> }
> @Override
> public <T> T get(final Contextual<T> component) {
> return delegate.get().get(component);
> }
> @Override
> public boolean isActive() {
> final Delegate instance = delegate.get();
> if (instance == null) {
> delegate.remove();
> return false;
> }
> return instance.isActive();
> }
> @Override
> public void destroy(final Contextual<?> contextual) {
> delegate.get().destroy(contextual);
> }
> public Delegate newInstance() {
> return new Delegate();
> }
> public void withContext(final Delegate value, final Runnable task) {
> delegate.set(value);
> try {
> task.run();
> } finally {
> delegate.remove();
> }
> }
> public void destroy(final Delegate delegate) {
> new ArrayList<>(delegate.componentInstanceMap.keySet()).forEach(delegate::destroy);
> }
> public class Delegate implements AlterableContext {
> private final Map<Contextual<?>, BeanInstanceBag<?>> componentInstanceMap = new HashMap<>();
> private Delegate() {
> // no-op
> }
> @Override
> public Class<? extends Annotation> getScope() {
> return CommandScoped.class;
> }
> @Override
> public <T> T get(final Contextual<T> component, final CreationalContext<T> creationalContext) {
> final BeanInstanceBag value = new BeanInstanceBag<>(creationalContext);
> return (T) ofNullable(componentInstanceMap.putIfAbsent(component, value)).orElse(value).create(component);
> }
> @Override
> public <T> T get(final Contextual<T> component) {
> return (T) ofNullable(componentInstanceMap.get(component)).map(b -> b.beanInstance).orElse(null);
> }
> @Override
> public void destroy(final Contextual<?> contextual) {
> ofNullable(componentInstanceMap.remove(contextual)).filter(b -> b.beanInstance != null).ifPresent(b -> {
> final Contextual c = contextual;
> c.destroy(b.beanInstance, b.beanCreationalContext);
> b.beanCreationalContext.release();
> });
> }
> @Override
> public boolean isActive() {
> return true;
> }
> }
> @RequiredArgsConstructor
> private static class BeanInstanceBag<T> {
> private final CreationalContext<T> beanCreationalContext;
> private T beanInstance;
> public T create(final Contextual<T> contextual) {
> if (beanInstance == null) {
> beanInstance = contextual.create(beanCreationalContext);
> }
> return beanInstance;
> }
> }
> }
> {code}
> This is a lot for finally just define (what the user wants) when a context is active.
> Therefore it would be awesome is the spec would provide a context builder. Raw api proposal could be:
> {code}
> void addContext(@Observes final AfterBeanDiscovery abd) {
> context = abd.contextBuilder().concurrent().scope(TheScoped.class).create();
> abd.addContext(context);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (CDI-663) Usage of repeatable qualifiers contradicts several statements in the spec
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-663?page=com.atlassian.jira.plugin.sy... ]
John Ament commented on CDI-663:
--------------------------------
The only cases where any of these can happen is repeatable annotations, so indicating what happens in these scenarios makes sense.
> Usage of repeatable qualifiers contradicts several statements in the spec
> -------------------------------------------------------------------------
>
> Key: CDI-663
> URL: https://issues.jboss.org/browse/CDI-663
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Tomas Remes
> Assignee: Tomas Remes
> Fix For: 2.0 .Final
>
>
> Using repeatable qualifier is in contradiction with {{11.3.12. Observer method resolution}}:
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{5.6.1. The Instance interface}}:
> | If two instances of the same qualifier type are passed to select(), an IllegalArgumentException is thrown.
> {{10.2.3. The Event interface}}
> | If two instances of the same qualifier type are passed to select(), an llegalArgumentException is thrown.
> {{11.3.6. Obtaining a Bean by type}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.13. Decorator resolution}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.14. Interceptor resolution}}
> | If two instances of the same interceptor binding type are given, an IllegalArgumentException is thrown.
> Should we remove this statement or make it more explicit by saying that this is true only for non-repeatable qualifiers/annotations?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (CDI-663) Usage of repeatable qualifiers contradicts several statements in the spec
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-663?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes reassigned CDI-663:
-------------------------------
Assignee: Tomas Remes
> Usage of repeatable qualifiers contradicts several statements in the spec
> -------------------------------------------------------------------------
>
> Key: CDI-663
> URL: https://issues.jboss.org/browse/CDI-663
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Tomas Remes
> Assignee: Tomas Remes
> Fix For: 2.0 .Final
>
>
> Using repeatable qualifier is in contradiction with {{11.3.12. Observer method resolution}}:
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{5.6.1. The Instance interface}}:
> | If two instances of the same qualifier type are passed to select(), an IllegalArgumentException is thrown.
> {{10.2.3. The Event interface}}
> | If two instances of the same qualifier type are passed to select(), an llegalArgumentException is thrown.
> {{11.3.6. Obtaining a Bean by type}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.13. Decorator resolution}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.14. Interceptor resolution}}
> | If two instances of the same interceptor binding type are given, an IllegalArgumentException is thrown.
> Should we remove this statement or make it more explicit by saying that this is true only for non-repeatable qualifiers/annotations?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (CDI-663) Usage of repeatable qualifiers contradicts several statements in the spec
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-663?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes reopened CDI-663:
-----------------------------
We need to update this also in javadoc.
> Usage of repeatable qualifiers contradicts several statements in the spec
> -------------------------------------------------------------------------
>
> Key: CDI-663
> URL: https://issues.jboss.org/browse/CDI-663
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Tomas Remes
> Fix For: 2.0 .Final
>
>
> Using repeatable qualifier is in contradiction with {{11.3.12. Observer method resolution}}:
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{5.6.1. The Instance interface}}:
> | If two instances of the same qualifier type are passed to select(), an IllegalArgumentException is thrown.
> {{10.2.3. The Event interface}}
> | If two instances of the same qualifier type are passed to select(), an llegalArgumentException is thrown.
> {{11.3.6. Obtaining a Bean by type}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.13. Decorator resolution}}
> | If two instances of the same qualifier type are given, an IllegalArgumentException is thrown.
> {{11.3.14. Interceptor resolution}}
> | If two instances of the same interceptor binding type are given, an IllegalArgumentException is thrown.
> Should we remove this statement or make it more explicit by saying that this is true only for non-repeatable qualifiers/annotations?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (CDI-666) simplify context implementation
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/CDI-666?page=com.atlassian.jira.plugin.sy... ]
George Gastaldi commented on CDI-666:
-------------------------------------
That looks cool. It could also introduce methods (using lamdas of course) to create and destroy the context and another one to retrieve the requested object in this scope
> simplify context implementation
> -------------------------------
>
> Key: CDI-666
> URL: https://issues.jboss.org/browse/CDI-666
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Romain Manni-Bucau
>
> Today implementing a context leads to implementing Context or AlterableContext interface.
> Then for Thread Local related scopes it leads to handle activation, deactivation (thread local set/remove) and delegation of the context to a sub context (implementing or not Context interface). Finally it requires a destroyEnd() method destroying all instances.
> It also requires the instance tracking and instantiation correctly (with lock or not depending the usage).
> Here is a schematic implementation (easier than previous paragraph to read ;)):
> {code}
> public class CommandContext implements AlterableContext {
> private final ThreadLocal<Delegate> delegate = new ThreadLocal<>();
> @Override
> public Class<? extends Annotation> getScope() {
> return CommandScoped.class;
> }
> @Override
> public <T> T get(final Contextual<T> component, final CreationalContext<T> creationalContext) {
> return delegate.get().get(component, creationalContext);
> }
> @Override
> public <T> T get(final Contextual<T> component) {
> return delegate.get().get(component);
> }
> @Override
> public boolean isActive() {
> final Delegate instance = delegate.get();
> if (instance == null) {
> delegate.remove();
> return false;
> }
> return instance.isActive();
> }
> @Override
> public void destroy(final Contextual<?> contextual) {
> delegate.get().destroy(contextual);
> }
> public Delegate newInstance() {
> return new Delegate();
> }
> public void withContext(final Delegate value, final Runnable task) {
> delegate.set(value);
> try {
> task.run();
> } finally {
> delegate.remove();
> }
> }
> public void destroy(final Delegate delegate) {
> new ArrayList<>(delegate.componentInstanceMap.keySet()).forEach(delegate::destroy);
> }
> public class Delegate implements AlterableContext {
> private final Map<Contextual<?>, BeanInstanceBag<?>> componentInstanceMap = new HashMap<>();
> private Delegate() {
> // no-op
> }
> @Override
> public Class<? extends Annotation> getScope() {
> return CommandScoped.class;
> }
> @Override
> public <T> T get(final Contextual<T> component, final CreationalContext<T> creationalContext) {
> final BeanInstanceBag value = new BeanInstanceBag<>(creationalContext);
> return (T) ofNullable(componentInstanceMap.putIfAbsent(component, value)).orElse(value).create(component);
> }
> @Override
> public <T> T get(final Contextual<T> component) {
> return (T) ofNullable(componentInstanceMap.get(component)).map(b -> b.beanInstance).orElse(null);
> }
> @Override
> public void destroy(final Contextual<?> contextual) {
> ofNullable(componentInstanceMap.remove(contextual)).filter(b -> b.beanInstance != null).ifPresent(b -> {
> final Contextual c = contextual;
> c.destroy(b.beanInstance, b.beanCreationalContext);
> b.beanCreationalContext.release();
> });
> }
> @Override
> public boolean isActive() {
> return true;
> }
> }
> @RequiredArgsConstructor
> private static class BeanInstanceBag<T> {
> private final CreationalContext<T> beanCreationalContext;
> private T beanInstance;
> public T create(final Contextual<T> contextual) {
> if (beanInstance == null) {
> beanInstance = contextual.create(beanCreationalContext);
> }
> return beanInstance;
> }
> }
> }
> {code}
> This is a lot for finally just define (what the user wants) when a context is active.
> Therefore it would be awesome is the spec would provide a context builder. Raw api proposal could be:
> {code}
> void addContext(@Observes final AfterBeanDiscovery abd) {
> context = abd.contextBuilder().concurrent().scope(TheScoped.class).create();
> abd.addContext(context);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (CDI-666) simplify context implementation
by Romain Manni-Bucau (JIRA)
Romain Manni-Bucau created CDI-666:
--------------------------------------
Summary: simplify context implementation
Key: CDI-666
URL: https://issues.jboss.org/browse/CDI-666
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Romain Manni-Bucau
Today implementing a context leads to implementing Context or AlterableContext interface.
Then for Thread Local related scopes it leads to handle activation, deactivation (thread local set/remove) and delegation of the context to a sub context (implementing or not Context interface). Finally it requires a destroyEnd() method destroying all instances.
It also requires the instance tracking and instantiation correctly (with lock or not depending the usage).
Here is a schematic implementation (easier than previous paragraph to read ;)):
{code}
public class CommandContext implements AlterableContext {
private final ThreadLocal<Delegate> delegate = new ThreadLocal<>();
@Override
public Class<? extends Annotation> getScope() {
return CommandScoped.class;
}
@Override
public <T> T get(final Contextual<T> component, final CreationalContext<T> creationalContext) {
return delegate.get().get(component, creationalContext);
}
@Override
public <T> T get(final Contextual<T> component) {
return delegate.get().get(component);
}
@Override
public boolean isActive() {
final Delegate instance = delegate.get();
if (instance == null) {
delegate.remove();
return false;
}
return instance.isActive();
}
@Override
public void destroy(final Contextual<?> contextual) {
delegate.get().destroy(contextual);
}
public Delegate newInstance() {
return new Delegate();
}
public void withContext(final Delegate value, final Runnable task) {
delegate.set(value);
try {
task.run();
} finally {
delegate.remove();
}
}
public void destroy(final Delegate delegate) {
new ArrayList<>(delegate.componentInstanceMap.keySet()).forEach(delegate::destroy);
}
public class Delegate implements AlterableContext {
private final Map<Contextual<?>, BeanInstanceBag<?>> componentInstanceMap = new HashMap<>();
private Delegate() {
// no-op
}
@Override
public Class<? extends Annotation> getScope() {
return CommandScoped.class;
}
@Override
public <T> T get(final Contextual<T> component, final CreationalContext<T> creationalContext) {
final BeanInstanceBag value = new BeanInstanceBag<>(creationalContext);
return (T) ofNullable(componentInstanceMap.putIfAbsent(component, value)).orElse(value).create(component);
}
@Override
public <T> T get(final Contextual<T> component) {
return (T) ofNullable(componentInstanceMap.get(component)).map(b -> b.beanInstance).orElse(null);
}
@Override
public void destroy(final Contextual<?> contextual) {
ofNullable(componentInstanceMap.remove(contextual)).filter(b -> b.beanInstance != null).ifPresent(b -> {
final Contextual c = contextual;
c.destroy(b.beanInstance, b.beanCreationalContext);
b.beanCreationalContext.release();
});
}
@Override
public boolean isActive() {
return true;
}
}
@RequiredArgsConstructor
private static class BeanInstanceBag<T> {
private final CreationalContext<T> beanCreationalContext;
private T beanInstance;
public T create(final Contextual<T> contextual) {
if (beanInstance == null) {
beanInstance = contextual.create(beanCreationalContext);
}
return beanInstance;
}
}
}
{code}
This is a lot for finally just define (what the user wants) when a context is active.
Therefore it would be awesome is the spec would provide a context builder. Raw api proposal could be:
{code}
void addContext(@Observes final AfterBeanDiscovery abd) {
context = abd.contextBuilder().concurrent().scope(TheScoped.class).create();
abd.addContext(context);
}
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[JBoss JIRA] (CDI-232) Relax requirements for built-in Instance
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-232?page=com.atlassian.jira.plugin.sy... ]
Work on CDI-232 started by John Ament.
--------------------------------------
> Relax requirements for built-in Instance
> ----------------------------------------
>
> Key: CDI-232
> URL: https://issues.jboss.org/browse/CDI-232
> Project: CDI Specification Issues
> Issue Type: Clarification
> Affects Versions: 1.1.EDR
> Reporter: Martin Kouba
> Assignee: John Ament
> Priority: Minor
> Labels: F2F2016
> Fix For: 2.0 .Final
>
>
> 5.6.2. The built-in Instance
> {quote}
> The container must provide a built-in bean with:
> * Instance<X> and Provider<X> for every legal bean type X in its set of bean types,
> * every qualifier type in its set of qualifier types,
> {quote}
> This type/qualifier requirements seem to be too strict. Maybe we should omit these and instead force implementation to satisfy every injection point for every legal bean type and corresponding qualifiers found in application... or something like that. I'm not sure about the wording.
> By the way Weld (2.0.0.Alpha2) does not fulfil these requirements at the moment.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years
[Vote] @Priority value order on ordered events
by Antoine Sabot-Durand
Hi all,
As already explained in a previous mail [1], some of us would like change
the current order of events to make the highest @Priority value first and
the lowest last. This change would be an alinement on how @Alternative
work (highest value being the first candidate).
If you agree to the change (highest to lowest) vote +1, if you disagree -1
and don't care 0. If you want to discuss thread is always open on [1] but
time is running out.
Vote will end Monday at 12:00 pm CET.
Thanks for your participation.
Antoine
[1] http://lists.jboss.org/pipermail/cdi-dev/2016-November/009330.html
8 years
