[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:
---------------------------------
Hi,
You are likely true that this section is not valid according to manifest specification (was looking at https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html). I was wondering where this comes from and finally discovered this definition in weld-parent pom (see related issue).
> 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)
6 years, 7 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 updated CDI-641:
------------------------------
Description:
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.
was:
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.
----
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.
> 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)
6 years, 7 months
[JBoss JIRA] (CDI-641) Invalid manifest section in cdi-api JAR
by Björn Kautler (JIRA)
Björn Kautler created CDI-641:
---------------------------------
Summary: 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: 2.0-EDR2, 1.0
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.
----
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)
6 years, 7 months
[JBoss JIRA] (CDI-640) Improve javadoc for SeContainer methods
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-640?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes reassigned CDI-640:
-------------------------------
Assignee: Tomas Remes
> Improve javadoc for SeContainer methods
> ---------------------------------------
>
> Key: CDI-640
> URL: https://issues.jboss.org/browse/CDI-640
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java SE Integration
> Affects Versions: 2.0-EDR2
> Reporter: Tomas Remes
> Assignee: Tomas Remes
> Priority: Minor
> Fix For: 2.0 .Final
>
>
> Javadoc for following methods doesn't say anything about {{IllegalStateException}} (which is mentioned in the spec text):
> * {{javax.enterprise.inject.se.SeContainer#close}}
> * {{javax.enterprise.inject.se.SeContainer#getBeanManager}}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
6 years, 7 months
[JBoss JIRA] (CDI-640) Improve javadoc for SeContainer methods
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-640?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes updated CDI-640:
----------------------------
Fix Version/s: 2.0 .Final
> Improve javadoc for SeContainer methods
> ---------------------------------------
>
> Key: CDI-640
> URL: https://issues.jboss.org/browse/CDI-640
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java SE Integration
> Affects Versions: 2.0-EDR2
> Reporter: Tomas Remes
> Assignee: Tomas Remes
> Priority: Minor
> Fix For: 2.0 .Final
>
>
> Javadoc for following methods doesn't say anything about {{IllegalStateException}} (which is mentioned in the spec text):
> * {{javax.enterprise.inject.se.SeContainer#close}}
> * {{javax.enterprise.inject.se.SeContainer#getBeanManager}}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
6 years, 7 months
[JBoss JIRA] (CDI-640) Improve javadoc for SeContainer methods
by Tomas Remes (JIRA)
Tomas Remes created CDI-640:
-------------------------------
Summary: Improve javadoc for SeContainer methods
Key: CDI-640
URL: https://issues.jboss.org/browse/CDI-640
Project: CDI Specification Issues
Issue Type: Bug
Components: Java SE Integration
Affects Versions: 2.0-EDR2
Reporter: Tomas Remes
Priority: Minor
Javadoc for following methods doesn't say anything about {{IllegalStateException}} (which is mentioned in the spec text):
* {{javax.enterprise.inject.se.SeContainer#close}}
* {{javax.enterprise.inject.se.SeContainer#getBeanManager}}
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
6 years, 7 months
[JBoss JIRA] (CDI-639) Clarify purpose of InjectionPointConfigurator.bean(Bean<?> bean) method
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/CDI-639?page=com.atlassian.jira.plugin.sy... ]
Tomas Remes updated CDI-639:
----------------------------
Fix Version/s: 2.0 .Final
> Clarify purpose of InjectionPointConfigurator.bean(Bean<?> bean) method
> -----------------------------------------------------------------------
>
> Key: CDI-639
> URL: https://issues.jboss.org/browse/CDI-639
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 2.0-EDR2
> Reporter: Tomas Remes
> Fix For: 2.0 .Final
>
>
> Dear EG,
> I would like to ask for clarification of {{javax.enterprise.inject.spi.builder.InjectionPointConfigurator#bean}} method. I am not really sure what's the benefit of this method and what would be the suitable use case for this method.
> I think using this method when I have my custom bean doesn't have any significant advantage since I can declare set of injection points in my custom bean impl.
> Maybe I would remove this method from the {{InjectionPointConfigurator}} interface.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
6 years, 7 months
[JBoss JIRA] (CDI-639) Clarify purpose of InjectionPointConfigurator.bean(Bean<?> bean) method
by Tomas Remes (JIRA)
Tomas Remes created CDI-639:
-------------------------------
Summary: Clarify purpose of InjectionPointConfigurator.bean(Bean<?> bean) method
Key: CDI-639
URL: https://issues.jboss.org/browse/CDI-639
Project: CDI Specification Issues
Issue Type: Clarification
Components: Portable Extensions
Affects Versions: 2.0-EDR2
Reporter: Tomas Remes
Dear EG,
I would like to ask for clarification of {{javax.enterprise.inject.spi.builder.InjectionPointConfigurator#bean}} method. I am not really sure what's the benefit of this method and what would be the suitable use case for this method.
I think using this method when I have my custom bean doesn't have any significant advantage since I can declare set of injection points in my custom bean impl.
Maybe I would remove this method from the {{InjectionPointConfigurator}} interface.
--
This message was sent by Atlassian JIRA
(v7.2.2#72004)
6 years, 7 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:
----------------------------------
For the record - {{AnnotationLiteral#hashCode()}} is already optimized for annotations with no members (see also https://github.com/cdi-spec/cdi/blob/master/api/src/main/java/javax/enter...), the same applies to {{#equals()}}. {{#toString()}} is not cached and I don't think it should be (by the way it's not even cached in the referenced OWB's {{EmptyAnnotationLiteral}}).
Also I don't think we should cache hashCode and toString for annotations with members - it could work in most cases but it's not 100%.
> 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
(v7.2.2#72004)
6 years, 7 months
Probably late to tomorrow's meeting
by John Ament
I'll probably be late, possibly not going to make it.
I do want to get a path forward on CDI-30. E.g.:
- Changes needed
- Clarifications in other sections of the spec
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.
6 years, 7 months
