[JBoss JIRA] (CDI-632) Possible conflict for Implicit bean archive definition between core and SE
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-632?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-632:
-------------------------------------
Description:
Section 12.1 (which should be satisfied in SE an EE) states:
bq. An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation as defined in Bean defining annotations.
And section 15.1 reads:
{quote}When running in Java SE, the container must extend the rules defined in Bean archives and also ensure that :
An archive which doesn’t contain a beans.xml file can’t be discovered as an implicit bean archive unless:
* the application is launched with system property javax.enterprise.inject.scan.implicit set to true, or
* the container was initialized with a parameter map containing an entry with javax.enterprise.inject.scan.implicit as key and Boolean.TRUE as value.{quote}
Perhaps this deserve a bit of clarification.
was:
Current implementation of CDI 2.0 EDR2 doesn't support implicit bean archive (see WELD-2233) where the spec says it is available in core and thus Java SE.
We need to clarify the spec or correct the impl...
> Possible conflict for Implicit bean archive definition between core and SE
> --------------------------------------------------------------------------
>
> Key: CDI-632
> URL: https://issues.jboss.org/browse/CDI-632
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java SE Integration
> Affects Versions: 2.0-EDR2
> Reporter: Antoine Sabot-Durand
>
> Section 12.1 (which should be satisfied in SE an EE) states:
> bq. An implicit bean archive is any other archive which contains one or more bean classes with a bean defining annotation as defined in Bean defining annotations.
> And section 15.1 reads:
> {quote}When running in Java SE, the container must extend the rules defined in Bean archives and also ensure that :
> An archive which doesn’t contain a beans.xml file can’t be discovered as an implicit bean archive unless:
> * the application is launched with system property javax.enterprise.inject.scan.implicit set to true, or
> * the container was initialized with a parameter map containing an entry with javax.enterprise.inject.scan.implicit as key and Boolean.TRUE as value.{quote}
> Perhaps this deserve a bit of clarification.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-632) Possible conflict for Implicit bean archive definition between core and SE
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-632?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-632:
-------------------------------------
Summary: Possible conflict for Implicit bean archive definition between core and SE (was: Does implicit bean archive should exist in Java SE)
> Possible conflict for Implicit bean archive definition between core and SE
> --------------------------------------------------------------------------
>
> Key: CDI-632
> URL: https://issues.jboss.org/browse/CDI-632
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Java SE Integration
> Affects Versions: 2.0-EDR2
> Reporter: Antoine Sabot-Durand
>
> Current implementation of CDI 2.0 EDR2 doesn't support implicit bean archive (see WELD-2233) where the spec says it is available in core and thus Java SE.
> We need to clarify the spec or correct the impl...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
[JBoss JIRA] (CDI-632) Does implicit bean archive should exist in Java SE
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-632:
----------------------------------------
Summary: Does implicit bean archive should exist in Java SE
Key: CDI-632
URL: https://issues.jboss.org/browse/CDI-632
Project: CDI Specification Issues
Issue Type: Clarification
Components: Java SE Integration
Affects Versions: 2.0-EDR2
Reporter: Antoine Sabot-Durand
Current implementation of CDI 2.0 EDR2 doesn't support implicit bean archive (see WELD-2233) where the spec says it is available in core and thus Java SE.
We need to clarify the spec or correct the impl...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
Accepting class type for simple (qualifier) annotations in APIs?
by arjan tijms
Hi,
Wouldn't it be convenient as the CDI API that now requires an Annotation
instance in various APIs, would also accept the class type of that
Annotation?
E.g. in BeanManager there's this method:
Set<Bean<?>> getBeans(Type beanType, Annotation... qualifiers)
This not rarely requires one to create an AnnotationLiteral, which is not
specifically difficult but a tad verbose. For qualifiers that have no
(binding) attributes, a simple Class would be much easier to use.
Thoughts?
Kind regards,
Arjan Tijms
8 years, 5 months
[JBoss JIRA] (CDI-631) Improve AnnotationLiteral for empty annotations
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-631?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-631:
-------------------------------------
Fix Version/s: 2.0 (discussion)
> Improve AnnotationLiteral for empty annotations
> -----------------------------------------------
>
> Key: CDI-631
> URL: https://issues.jboss.org/browse/CDI-631
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Mark Struberg
> Fix For: 2.0 (discussion)
>
>
> Annotation hashCode() and equals() operations are fairly expensive as they always invoke getDeclaredMethods() even if there are no such. And getDeclaredMethods involves the SecurityManager + wrapper classes + Exception handling + + +
> That's horrible expensive.
> In OWB I improved this by introducing an own base class for dynamic annotations which do not have any members:
> https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/...
> The method returns a hardcoded String for toString(), returns hardcoded 0 as hashCode and the equals() method invokes the equals on the annotation type.
> We might support this improvements directly in the AnnotationLiteral class or introduce a similar 2nd class especially for empty annotations?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 5 months
Which version of HttpServletRequest is injected?
by arjan tijms
Hi,
The CDI spec defines a built-in bean for the type HttpServletRequest. In
3.8 it says:
"A servlet container must provide the following built-in beans, all of
which have qualifier @Default:
a bean with bean type javax.servlet.http.HttpServletRequest, allowing
injection of a reference to the HttpServletRequest"
An HttpServletRequest however can be wrapped multiple times and by multiple
artefacts. I.e. by a ServerAuthModule, Filter and a RequestDispatcher.
The question now is; which version of the HttpServletRequest is supposed to
be injected?
* The first one in the chain?
* The last one in the chain?
* The current one at a given point in the chain?
A little bit of experimenting seems to indicate it's now often "one of the
first ones", e.g. the one that happened to be current when e.g. a
ServletRequestListener that initialises a specific CDI implementation is
called.
I think this is a little confusing, as working with an injected request can
now totally ignore the request wrapping that has been done and break an
application badly.
Thoughts?
Kind regards,
Arjan Tijms
8 years, 6 months
Should javax.enterprise.inject.Produces be inherited?
by John Ament
All,
I was just thinking about alternatives and producer methods. Suppose I have the following bean:
@ApplicationScoped
public class Boop {
@Produces
@ApplicationScoped
public Simpler makeSimpler() {
return new Simpler("Boop");
}
}
If I want to override the producer method, I need to declare fully:
@Alternative
@Priority(100)
@ApplicationScoped
public class BoopAlternative extends Boop{
@Override
@Produces
public Simpler makeSimpler() {
return new Simpler("Boop2");
}
}
For some reason, scopes are inherited, but the produces annotation is not. At least in the case of a producer method, it seems like it would be useful for @Produces to be inherited as well.
John
________________________________
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
8 years, 6 months
[JBoss JIRA] (CDI-631) Improve AnnotationLiteral for empty annotations
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-631?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-631:
----------------------------------
Well, values should not change but it's possible. There was already an attempt to improve this - see also CDI-149.
> Improve AnnotationLiteral for empty annotations
> -----------------------------------------------
>
> Key: CDI-631
> URL: https://issues.jboss.org/browse/CDI-631
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Mark Struberg
>
> Annotation hashCode() and equals() operations are fairly expensive as they always invoke getDeclaredMethods() even if there are no such. And getDeclaredMethods involves the SecurityManager + wrapper classes + Exception handling + + +
> That's horrible expensive.
> In OWB I improved this by introducing an own base class for dynamic annotations which do not have any members:
> https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/...
> The method returns a hardcoded String for toString(), returns hardcoded 0 as hashCode and the equals() method invokes the equals on the annotation type.
> We might support this improvements directly in the AnnotationLiteral class or introduce a similar 2nd class especially for empty annotations?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (CDI-631) Improve AnnotationLiteral for empty annotations
by Mark Struberg (JIRA)
[ https://issues.jboss.org/browse/CDI-631?page=com.atlassian.jira.plugin.sy... ]
Mark Struberg commented on CDI-631:
-----------------------------------
The other question is whether we can cache the hashCode and toString as it should not be subject to changes, right?
I mean do we allow AnnotationLiteral subclasses to modify their values during runtime?
That would conflict with the Annotation definition imo.
> Improve AnnotationLiteral for empty annotations
> -----------------------------------------------
>
> Key: CDI-631
> URL: https://issues.jboss.org/browse/CDI-631
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Mark Struberg
>
> Annotation hashCode() and equals() operations are fairly expensive as they always invoke getDeclaredMethods() even if there are no such. And getDeclaredMethods involves the SecurityManager + wrapper classes + Exception handling + + +
> That's horrible expensive.
> In OWB I improved this by introducing an own base class for dynamic annotations which do not have any members:
> https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/...
> The method returns a hardcoded String for toString(), returns hardcoded 0 as hashCode and the equals() method invokes the equals on the annotation type.
> We might support this improvements directly in the AnnotationLiteral class or introduce a similar 2nd class especially for empty annotations?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (CDI-631) Improve AnnotationLiteral for empty annotations
by Mark Struberg (JIRA)
Mark Struberg created CDI-631:
---------------------------------
Summary: Improve AnnotationLiteral for empty annotations
Key: CDI-631
URL: https://issues.jboss.org/browse/CDI-631
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Mark Struberg
Annotation hashCode() and equals() operations are fairly expensive as they always invoke getDeclaredMethods() even if there are no such. And getDeclaredMethods involves the SecurityManager + wrapper classes + Exception handling + + +
That's horrible expensive.
In OWB I improved this by introducing an own base class for dynamic annotations which do not have any members:
https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/...
The method returns a hardcoded String for toString(), returns hardcoded 0 as hashCode and the equals() method invokes the equals on the annotation type.
We might support this improvements directly in the AnnotationLiteral class or introduce a similar 2nd class especially for empty annotations?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months