[JBoss JIRA] (CDI-481) Introduce AnnotatedParameter.getJavaParameter()
by Romain Manni-Bucau (JIRA)
[ https://issues.jboss.org/browse/CDI-481?page=com.atlassian.jira.plugin.sy... ]
Romain Manni-Bucau commented on CDI-481:
----------------------------------------
Can be interesting to align it on BVal with parameter naming, no?
> Introduce AnnotatedParameter.getJavaParameter()
> -----------------------------------------------
>
> Key: CDI-481
> URL: https://issues.jboss.org/browse/CDI-481
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Reporter: Jozef Hartinger
>
> Make it possible to obtain the Java Reflection object representing the parameter. This is in line with
> AnnotatedField.getJavaMember()
> AnnotatedMethod.getJavaMember()
> AnnotatedConstructor.getJavaMember()
> Can be implemented as a default method such as:
> {code:JAVA}
> default Parameter getJavaParameter() {
> Member member = getDeclaringCallable().getJavaMember();
> if (!(member instanceof Executable)) {
> throw new IllegalStateException("Parameter does not belong to an executable " + member);
> }
> Executable executable = (Executable) member;
> return executable.getParameters()[getPosition()];
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (CDI-481) Introduce AnnotatedParameter.getJavaParameter()
by Jozef Hartinger (JIRA)
Jozef Hartinger created CDI-481:
-----------------------------------
Summary: Introduce AnnotatedParameter.getJavaParameter()
Key: CDI-481
URL: https://issues.jboss.org/browse/CDI-481
Project: CDI Specification Issues
Issue Type: Feature Request
Components: Portable Extensions
Reporter: Jozef Hartinger
Make it possible to obtain the Java Reflection object representing the parameter. This is in line with
AnnotatedField.getJavaMember()
AnnotatedMethod.getJavaMember()
AnnotatedConstructor.getJavaMember()
Can be implemented as a default method such as:
{code:JAVA}
default Parameter getJavaParameter() {
Member member = getDeclaringCallable().getJavaMember();
if (!(member instanceof Executable)) {
throw new IllegalStateException("Parameter does not belong to an executable " + member);
}
Executable executable = (Executable) member;
return executable.getParameters()[getPosition()];
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (CDI-480) Introduce real link between spec doc and TCK
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-480?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-480:
-------------------------------------
Description:
One of the nicest thing in CDI TCK is the audit files. These XML files (like : https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/resources/t...) list all challenges coming from the specification and allow to bind a given test to a given challenge thanks to {{@SpecAssertion}} annotation (see https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jb... for instance).
This system is great to know what assertions are broken, retrieve what spec rule is tested from the code and have nice report on spec coverage in TCK.
The only weakness here is that these audit files are only maintained "by hand" when we could (perhaps) have an automatic or semi-automatic way of generating them or at least checking them against the spec.
Since the spec doc is generated with Asciidoctor, this could be done by creating an Asciidoctor macro or extension (not sure of the terminology) and add a meta data set to each rule written in the spec (allowing to have one or more test for one rule). These meta could be used to help generate the xml file for the TCK or at least check that they contains all rules from the spec.
The immediate benefit I see here would be :
# make the spec contributors more concerned about TCK
# reduce the risk of forgetting rules in TCK
# produce a version of the spec with links to TCK test
# reduce the fear of refactoring the spec if needed
To make short, if this "unification" could be done, it would probably give us more efficiency and improve spec and TCK quality.
was:
One of the nicest thing in CDI TCK is the audit files. These XML files (like : https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/resources/t...) list all challenges coming from the specification and allow to bind a given test to a given challenge thanks to {{@SpecAssertion}} annotation (see https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jb... for instance).
This system is great to know what assertions are broken, retrieve what spec rule is tested from the code and have nice report on spec coverage in TCK.
The only weakness here is that these audit files are only maintained "by hand" when we could (perhaps) have an automatic or semi-automatic way of generating or at least checking these file against the spec.
This could be done by creating an Asciidoc macro or extension (not sure of the terminology) and add a meta data set to each rule written in the spec (allowing to have one or more test for one rule). These meta could be used to help generate the xml file for the TCK or at least check that they contains all rules from the spec.
The immediate benefit I see here would be :
# make the spec contributors more concerned about TCK
# reduce the risk of forgetting rules in TCK
# produce a version of the spec with links to TCK test
# reduce the fear of refactoring the spec if needed
To make short, if this "unification" could be done, it would probably give us more efficiency and improve spec and TCK quality.
> Introduce real link between spec doc and TCK
> --------------------------------------------
>
> Key: CDI-480
> URL: https://issues.jboss.org/browse/CDI-480
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Affects Versions: 1.1.Final
> Reporter: Antoine Sabot-Durand
>
> One of the nicest thing in CDI TCK is the audit files. These XML files (like : https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/resources/t...) list all challenges coming from the specification and allow to bind a given test to a given challenge thanks to {{@SpecAssertion}} annotation (see https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jb... for instance).
> This system is great to know what assertions are broken, retrieve what spec rule is tested from the code and have nice report on spec coverage in TCK.
> The only weakness here is that these audit files are only maintained "by hand" when we could (perhaps) have an automatic or semi-automatic way of generating them or at least checking them against the spec.
> Since the spec doc is generated with Asciidoctor, this could be done by creating an Asciidoctor macro or extension (not sure of the terminology) and add a meta data set to each rule written in the spec (allowing to have one or more test for one rule). These meta could be used to help generate the xml file for the TCK or at least check that they contains all rules from the spec.
> The immediate benefit I see here would be :
> # make the spec contributors more concerned about TCK
> # reduce the risk of forgetting rules in TCK
> # produce a version of the spec with links to TCK test
> # reduce the fear of refactoring the spec if needed
>
> To make short, if this "unification" could be done, it would probably give us more efficiency and improve spec and TCK quality.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (CDI-480) Introduce real link between spec doc and TCK
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-480:
----------------------------------------
Summary: Introduce real link between spec doc and TCK
Key: CDI-480
URL: https://issues.jboss.org/browse/CDI-480
Project: CDI Specification Issues
Issue Type: Feature Request
Affects Versions: 1.1.Final
Reporter: Antoine Sabot-Durand
One of the nicest thing in CDI TCK is the audit files. These XML files (like : https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/resources/t...) list all challenges coming from the specification and allow to bind a given test to a given challenge thanks to {{@SpecAssertion}} annotation (see https://github.com/cdi-spec/cdi-tck/blob/master/impl/src/main/java/org/jb... for instance).
This system is great to know what assertions are broken, retrieve what spec rule is tested from the code and have nice report on spec coverage in TCK.
The only weakness here is that these audit files are only maintained "by hand" when we could (perhaps) have an automatic or semi-automatic way of generating or at least checking these file against the spec.
This could be done by creating an Asciidoc macro or extension (not sure of the terminology) and add a meta data set to each rule written in the spec (allowing to have one or more test for one rule). These meta could be used to help generate the xml file for the TCK or at least check that they contains all rules from the spec.
The immediate benefit I see here would be :
# make the spec contributors more concerned about TCK
# reduce the risk of forgetting rules in TCK
# produce a version of the spec with links to TCK test
# reduce the fear of refactoring the spec if needed
To make short, if this "unification" could be done, it would probably give us more efficiency and improve spec and TCK quality.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (CDI-45) Optional Injection Points
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-45?page=com.atlassian.jira.plugin.sys... ]
Martin Kouba commented on CDI-45:
---------------------------------
I don't really see any benefit from introducing any additional interface, aside from performance. And some performance issues may be partially solved by implementation.
+1 for introducing a new convenient method {{Instance.isResolved()}} (or any other better name).
> Optional Injection Points
> -------------------------
>
> Key: CDI-45
> URL: https://issues.jboss.org/browse/CDI-45
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Resolution
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Fix For: 2.0 (discussion)
>
>
> There are occoasions where it may be useful for some injection points to be optional, e.g.
> @Inject
> @Optional
> MyBean bean;
> This would behave the same as a normal injection point, however it will not cause the deployment to fail if it is not satisified.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (CDI-458) Give the possibility to deactivate an observer in ProcessObserverMethod
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-458?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-458:
----------------------------------
Looks like a good idea. However, we should also clarify that POM is not fired for container lifecycle events. Although it makes sense it's not explicitly stated anywhere. Furthermore, it's not clear whether POM is fired for *non-container lifecycle events* declared on an extension (AFAIK Weld does not fire POM, nor PIP, for these).
Note that "11.5. Container lifecycle events":
{quote}
Service providers may have observer methods, which *may observe any event*, including any container lifecycle event, and obtain an injected BeanManager reference...
{quote}
and "12.4.3. Bean discovery":
{quote}
For each enabled bean, the container must search the class for observer methods, and for each observer method:
* ...
* fire an event of type ProcessObserverMethod, as defined in ProcessObserverMethod event.
{quote}
> Give the possibility to deactivate an observer in ProcessObserverMethod
> -----------------------------------------------------------------------
>
> Key: CDI-458
> URL: https://issues.jboss.org/browse/CDI-458
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events, Portable Extensions
> Affects Versions: 1.2.Final
> Reporter: Antoine Sabot-Durand
> Fix For: 2.0 (discussion)
>
>
> Today if a user want to deactivate an observer at deployment time, she needs to observes {{ProcessAnnotatedType}} with {{(a)WithAnnotation(Observes.class)}} and replace the annotatedType by a new one without the {{@Observes}} annotation. It's quite heavy to manage.
> We could add a {{veto()}} method in {{ProcessObserverMethod}} to do this in a far easier and intuitive way.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (CDI-104) Support automatic dependency injection for non-managed objects
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-104?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand resolved CDI-104.
--------------------------------------
Fix Version/s: 1.1.Final
(was: TBD)
Resolution: Done
> Support automatic dependency injection for non-managed objects
> --------------------------------------------------------------
>
> Key: CDI-104
> URL: https://issues.jboss.org/browse/CDI-104
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Dan Allen
> Fix For: 1.1.Final
>
>
> Allow objects created using the "new" keyword (or created by some other means) to be injected automatically.
> Conceptually it would look something like this:
> @AutoInject
> public class AccountService {
> private final Account account;
> @Inject
> private PaymentProcessor paymentProcessor;
> AccountService(Account account) {
> this.account = account;
> }
> public void doPayment(double amount) {
> paymentProcessor.processPayment(account, amount);
> }
> }
> We could then create the object using new and the fields will still be injected:
> AccountService a = new AccountService(account);
> a.doPayment(10);
> The inverse design would also be an option. An instance of Account could be retrieved from JPA and the AccountService would be injected into it during construction.
> To implement this feature may require a javaagent, which will modify the bytecode of @AutoInject annotated classes as they are loaded, so that the constructor bytecode looks up the values to inject and sets the injected field values appropriately. (There are other options suggested in the linked thread).
> The primary use case for this feature is to support rich domain models, though the usefulness of this feature extends beyond this case, so I don't think the feature should be dismissed if you don't agree with the rich domain models design.
> The feature also brings the "new" keyword back into the picture of modern programming. You can still create objects in the classic way, but benefit from modern programming model patterns (specifically CDI).
> Spring has a similar feature in it's AOP package: http://static.springsource.org/spring/docs/3.0.x/spring-framework-referen...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
[JBoss JIRA] (CDI-104) Support automatic dependency injection for non-managed objects
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-104?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-104:
------------------------------------------
Yes [~stefanutti], but in a less automatic way ;).
> Support automatic dependency injection for non-managed objects
> --------------------------------------------------------------
>
> Key: CDI-104
> URL: https://issues.jboss.org/browse/CDI-104
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.0
> Reporter: Dan Allen
> Fix For: 1.1.Final
>
>
> Allow objects created using the "new" keyword (or created by some other means) to be injected automatically.
> Conceptually it would look something like this:
> @AutoInject
> public class AccountService {
> private final Account account;
> @Inject
> private PaymentProcessor paymentProcessor;
> AccountService(Account account) {
> this.account = account;
> }
> public void doPayment(double amount) {
> paymentProcessor.processPayment(account, amount);
> }
> }
> We could then create the object using new and the fields will still be injected:
> AccountService a = new AccountService(account);
> a.doPayment(10);
> The inverse design would also be an option. An instance of Account could be retrieved from JPA and the AccountService would be injected into it during construction.
> To implement this feature may require a javaagent, which will modify the bytecode of @AutoInject annotated classes as they are loaded, so that the constructor bytecode looks up the values to inject and sets the injected field values appropriately. (There are other options suggested in the linked thread).
> The primary use case for this feature is to support rich domain models, though the usefulness of this feature extends beyond this case, so I don't think the feature should be dismissed if you don't agree with the rich domain models design.
> The feature also brings the "new" keyword back into the picture of modern programming. You can still create objects in the classic way, but benefit from modern programming model patterns (specifically CDI).
> Spring has a similar feature in it's AOP package: http://static.springsource.org/spring/docs/3.0.x/spring-framework-referen...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 2 months
