[JBoss JIRA] (CDI-643) Provide a way to easily configure injection point of an InjectionTarget
by Matej Novotny (JIRA)
[ https://issues.jboss.org/browse/CDI-643?page=com.atlassian.jira.plugin.sy... ]
Matej Novotny commented on CDI-643:
-----------------------------------
bq. I think we should add BeanManager.createAnnotatedTypeConfigurator()
I think this relates to lengthy conversations we had around {{Configurators}} and their usage outside of container lifecycle events. I think there were some implementation challenges which limited us in this way.
> Provide a way to easily configure injection point of an InjectionTarget
> -----------------------------------------------------------------------
>
> Key: CDI-643
> URL: https://issues.jboss.org/browse/CDI-643
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Antoine Sabot-Durand
> Fix For: 2.0 .Final
>
>
> Creating an {{InjectionTarget}} requires an AnnotatedType. It is often convenient to create a custom {{AnnotatedType}} to add injection points in it (i.e. add {{@Inject}} on fields or methods).
> We Introduced the {{AnnotatedTypeConfigurator}} helper but didn't provide a way to use it to create an {{InjectionTarget}}.
> I think we should add {{BeanManager.createAnnotatedTypeConfigurator()}} to solve this and perhaps simplify other places where we could use an {{AnnotatedTypeConfigurator}} like in CDI-642
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
7 years, 5 months
[JBoss JIRA] (CDI-643) Provide a way to easily configure injection point of an InjectionTarget
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-643:
----------------------------------------
Summary: Provide a way to easily configure injection point of an InjectionTarget
Key: CDI-643
URL: https://issues.jboss.org/browse/CDI-643
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Antoine Sabot-Durand
Creating an {{InjectionTarget}} requires an AnnotatedType. It is often convenient to create a custom {{AnnotatedType}} to add injection points in it (i.e. add {{@Inject}} on fields or methods).
We Introduced the {{AnnotatedTypeConfigurator}} helper but didn't provide a way to use it to create an {{InjectionTarget}}.
I think we should add {{BeanManager.createAnnotatedTypeConfigurator()}} to solve this and perhaps simplify other places where we could use an {{AnnotatedTypeConfigurator}} like in CDI-642
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
7 years, 6 months
[JBoss JIRA] (CDI-643) Provide a way to easily configure injection point of an InjectionTarget
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-643?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-643:
-------------------------------------
Fix Version/s: 2.0 .Final
> Provide a way to easily configure injection point of an InjectionTarget
> -----------------------------------------------------------------------
>
> Key: CDI-643
> URL: https://issues.jboss.org/browse/CDI-643
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Antoine Sabot-Durand
> Fix For: 2.0 .Final
>
>
> Creating an {{InjectionTarget}} requires an AnnotatedType. It is often convenient to create a custom {{AnnotatedType}} to add injection points in it (i.e. add {{@Inject}} on fields or methods).
> We Introduced the {{AnnotatedTypeConfigurator}} helper but didn't provide a way to use it to create an {{InjectionTarget}}.
> I think we should add {{BeanManager.createAnnotatedTypeConfigurator()}} to solve this and perhaps simplify other places where we could use an {{AnnotatedTypeConfigurator}} like in CDI-642
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
7 years, 6 months
[JBoss JIRA] (CDI-642) Allow defining interceptor binding or qualifier via an AnnotatedTypeConfigurator in BeforeBeandiscovery
by Antoine Sabot-Durand (JIRA)
Antoine Sabot-Durand created CDI-642:
----------------------------------------
Summary: Allow defining interceptor binding or qualifier via an AnnotatedTypeConfigurator in BeforeBeandiscovery
Key: CDI-642
URL: https://issues.jboss.org/browse/CDI-642
Project: CDI Specification Issues
Issue Type: Feature Request
Affects Versions: 2.0-EDR2
Reporter: Antoine Sabot-Durand
We should consider adding a new version of {{BeforeBeanDiscovery.addInterceptorBinding()}} and {{BeforeBeanDiscovery.addQualifier()}} methods returning an {{AnnotatedTypeConfigurator}} to ease addition of of 3rd party annotation as interceptor binding or qualifier.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
7 years, 6 months
[JBoss JIRA] (CDI-641) Invalid manifest section in cdi-api JAR
by Björn Kautler (JIRA)
[ https://issues.jboss.org/browse/CDI-641?page=com.atlassian.jira.plugin.sy... ]
Björn Kautler commented on CDI-641:
-----------------------------------
[~ljnelson] well, there maybe is room for interpretation, but let me also quote another sentence from the spec a bit above yours:
{quote}The individual sections define various attributes for packages or files contained in this JAR file. [...] Each section must start with an attribute with the name as "Name", and the value must be a relative path to the file, or an absolute URL referencing data outside the archive.{quote}
I interpret this in a way that means if the section id is not an absolute URL, the folder or file has to exist in the JAR, if not it is considered missing and thus tampered with. But I may interpret it wrongly of course.
But even if I interpret it wrongly, having such dummy sections has just negative effects (more RAM needed, more CPU needed, more IO needed, triggering bugs unnecessarily :-) ), while it does not really gain much. How often did you look at a manifest to get such a piece of information and would it be that much harder to read it from the main section instead of from a dedicated section?
> Invalid manifest section in cdi-api JAR
> ---------------------------------------
>
> Key: CDI-641
> URL: https://issues.jboss.org/browse/CDI-641
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: 1.0, 2.0-EDR2
> Reporter: Björn Kautler
>
> In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}.
> This violates that JAR specification.
> A section in the manifest always refers to an entry in the JAR.
> If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest.
> Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file.
> ----
> In my concrete use-case this happened with other JARs with invalid manifest entries:
> - I have signed those JARs and included them in a WebStart application
> - I started the application with 8u102 32-bit {{javaws}}
> - The JARs were downloaded and their entries signatures verified
> - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed
> This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse:
> - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM
> - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again
> - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between
> - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution
> Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
7 years, 6 months
[JBoss JIRA] (CDI-641) Invalid manifest section in cdi-api JAR
by Laird Nelson (JIRA)
[ https://issues.jboss.org/browse/CDI-641?page=com.atlassian.jira.plugin.sy... ]
Laird Nelson commented on CDI-641:
----------------------------------
Where in the manifest specification does it state that per-entry attributes must have a corresponding jar file entry?
I read this:
bq. Per-entry attributes apply only to the individual JAR file entry to which the manifest entry is associated with.
Rephrased so it is valid English:
bq. Per-entry attributes apply only to the individual JAR file entry with which the manifest entry is associated.
Then a {{Build-Info}} manifest per-entry attribute would apply only to a {{Build-Info}} jar file entry. Let us suppose that no such entry exists. Does this render the {{Build-Info}} per-entry attribute invalid? I don't read it that way. I read this as saying only: the {{Build-Info}} per-entry attribute _would_ apply to a jar file entry named {{Build-Info}}, but since no such entry exists, this per-entry attribute has undefined behavior, which is of course exactly what it's being used for at the moment.
(I have no stake in the presence or absence of this particular per-entry attribute, nor in this bug. I just want to make sure that I am properly understanding the manifest specification in this regard.)
> Invalid manifest section in cdi-api JAR
> ---------------------------------------
>
> Key: CDI-641
> URL: https://issues.jboss.org/browse/CDI-641
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: 1.0, 2.0-EDR2
> Reporter: Björn Kautler
>
> In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}.
> This violates that JAR specification.
> A section in the manifest always refers to an entry in the JAR.
> If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest.
> Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file.
> ----
> In my concrete use-case this happened with other JARs with invalid manifest entries:
> - I have signed those JARs and included them in a WebStart application
> - I started the application with 8u102 32-bit {{javaws}}
> - The JARs were downloaded and their entries signatures verified
> - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed
> This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse:
> - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM
> - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again
> - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between
> - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution
> Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
7 years, 6 months
[JBoss JIRA] (CDI-641) Invalid manifest section in cdi-api JAR
by Björn Kautler (JIRA)
[ https://issues.jboss.org/browse/CDI-641?page=com.atlassian.jira.plugin.sy... ]
Björn Kautler commented on CDI-641:
-----------------------------------
Yes, I think so. If that PR gets applied and all use the new parent (for me it is cdi-api and weld-se), then it should be fine.
> Invalid manifest section in cdi-api JAR
> ---------------------------------------
>
> Key: CDI-641
> URL: https://issues.jboss.org/browse/CDI-641
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: 1.0, 2.0-EDR2
> Reporter: Björn Kautler
>
> In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}.
> This violates that JAR specification.
> A section in the manifest always refers to an entry in the JAR.
> If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest.
> Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file.
> ----
> In my concrete use-case this happened with other JARs with invalid manifest entries:
> - I have signed those JARs and included them in a WebStart application
> - I started the application with 8u102 32-bit {{javaws}}
> - The JARs were downloaded and their entries signatures verified
> - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed
> This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse:
> - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM
> - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again
> - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between
> - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution
> Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
7 years, 6 months
[JBoss JIRA] (CDI-641) Invalid manifest section in cdi-api JAR
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-641?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes commented on CDI-641:
---------------------------------
[~vampire] I see. Can you please check if https://github.com/weld/parent/pull/6 can solve your issue? Thank's in advance.
> Invalid manifest section in cdi-api JAR
> ---------------------------------------
>
> Key: CDI-641
> URL: https://issues.jboss.org/browse/CDI-641
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: 1.0, 2.0-EDR2
> Reporter: Björn Kautler
>
> In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}.
> This violates that JAR specification.
> A section in the manifest always refers to an entry in the JAR.
> If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest.
> Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file.
> ----
> In my concrete use-case this happened with other JARs with invalid manifest entries:
> - I have signed those JARs and included them in a WebStart application
> - I started the application with 8u102 32-bit {{javaws}}
> - The JARs were downloaded and their entries signatures verified
> - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed
> This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse:
> - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM
> - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again
> - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between
> - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution
> Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
7 years, 6 months
[JBoss JIRA] (CDI-641) Invalid manifest section in cdi-api JAR
by Björn Kautler (JIRA)
[ https://issues.jboss.org/browse/CDI-641?page=com.atlassian.jira.plugin.sy... ]
Björn Kautler commented on CDI-641:
-----------------------------------
Yep, most older JBoss libs that us jboss-parent 6 or 7 have the same problem. In jboss-parent 8 and newer this is fixed by adding the information to the main section instead of to an own section. :-)
> Invalid manifest section in cdi-api JAR
> ---------------------------------------
>
> Key: CDI-641
> URL: https://issues.jboss.org/browse/CDI-641
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Packaging and Deployment
> Affects Versions: 1.0, 2.0-EDR2
> Reporter: Björn Kautler
>
> In the {{MANIFEST.MF}} of your {{cdi-api}} JAR you have a section {{Build-Information}}.
> This violates that JAR specification.
> A section in the manifest always refers to an entry in the JAR.
> If you have sections in the manifest that do not refer to an entry in the JAR, it is assumed that the JAR was tampered with as there are entries missing that are referenced in the manifest.
> Please either remove this section and include the entries in that secion in the main section which is according to the specification or include a file called {{Build-Information}} at the root of your JAR file.
> ----
> In my concrete use-case this happened with other JARs with invalid manifest entries:
> - I have signed those JARs and included them in a WebStart application
> - I started the application with 8u102 32-bit {{javaws}}
> - The JARs were downloaded and their entries signatures verified
> - As there were entries in the manifest that are not present in the JAR, the file was not seen as completely signed with one signature, but Java remembered for each entry with which signature it was signed
> This already is not too nice as it slows down the application as now for each class that gets loaded the signature has to be retrieved from a map and a list instead of having just one signature for all entries. But it gets much worse:
> - The acutal application was to be executed with 8u102 64-bit, so the 32-bit one wrote its session information out into files, including the information about verified JARs and also their entries if needed, and starts the 64-bit JVM
> - The 64-bit JVM loads this session information and thus does not have to do the time-consuming verification of the JARs all over again
> - Unfortunately since 8u91 or so there is a bug in this session reading and writing algorithm, so that some of the entry names get crippled with additional characters in-between
> - If now a class should be loaded that has such a crippled entry in the JAR-entry-to-signature map, the entry is not found and the class is considered as not signed which will block the application from further execution
> Of course this second part is a bug in Java, but it would work flawlessly if the JARs would not have invalid sections.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
7 years, 6 months