[jira] [Commented] (DELTASPIKE-1473) Improve dependency consistency in JSF module (dependency-analyze + requireExplicitDependencyScope)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848147#comment-17848147
]
ASF subversion and git services commented on DELTASPIKE-1473:
-
Commit 0fa754fec4bd6871d64b8d3b934da44daa64f5b1 in deltaspike's branch
refs/heads/master from Thomas Andraschko
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=0fa754fec ]
Merge pull request #160 from cmunier/DELTASPIKE-1473
DELTASPIKE-1473: Improved dependency consistency in the JSF module
> Improve dependency consistency in JSF module (dependency-analyze +
> requireExplicitDependencyScope)
> --
>
> Key: DELTASPIKE-1473
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1473
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
> {{analyze-only}} goal of {{maven-dependency-plugin}} so that dependency
> scopes that are to broad may come to attention while executing the build. In
> addition I find it helpful to activate the maven-enforcer-plugin with the
> rule {{requireExplicitDependencyScope}} so that an explicit scope has to be
> defined for each dependency.
> By doing this, I dicovered the following obsolete dependencies in the JSF
> module:
> {noformat}
> api -> jakarta.el-api (compile)
> impl -> deltaspike-proxy-module-api (compile)
> impl -> xml-apis (test)
> {noformat}
> The following dependencies are used transitively, but are not explicitely
> defined:
> {noformat}
> api -> junit-jupiter-api (test)
> impl -> arquillian-container-test-api (test)
> impl -> arquillian-junit-core (test)
> impl -> arquillian-test-api (test)
> impl -> shrinkwrap-api (test)
> impl -> selenium-api (test)
> impl -> selenium-support (test)
> {noformat}
> The following scopes seem to be too broad:
> {noformat}
> impl -> jakarta.el-api (compile)
> impl -> tomcat-servlet-api (compile)
> {noformat}
> I think we should always declare Jakarta EE APIs as "provided", because an
> Application Server already supplies the correct API version fitting its
> runtime.
> I will supply a PR to show my idea.
> If you like this idea, we could transfer this configuration to other modules.
> The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
> could then be moved up to one of its parents or distributed according to
> modules that inherit dependencies to their children.
> Further questions:
> * Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
> (optional) dependency of {{jsf-impl}} so that it will likely be automatically
> be included in the classpath? Or should it rather not be included by default,
> leaving it up to the consumer?
> * Should compile/provided dependency {{tomcat-servlet-api}} be changed to
> Jakarta Servlet API?
> * Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
> seems to have been used accidentally and only within this single project)?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1473) Improve dependency consistency in JSF module (dependency-analyze + requireExplicitDependencyScope)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17848146#comment-17848146
]
ASF subversion and git services commented on DELTASPIKE-1473:
-
Commit a598e725d46b5e588858c18ad2cbc3a3dba23163 in deltaspike's branch
refs/heads/master from Christian Munier
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=a598e725d ]
DELTASPIKE-1473: Improved dependency consistency in the JSF module
- removed obsolete dependencies
- added used transitive dependencies as explicite dependencies
- narrowed down dependency scopes that were too broad
> Improve dependency consistency in JSF module (dependency-analyze +
> requireExplicitDependencyScope)
> --
>
> Key: DELTASPIKE-1473
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1473
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
> {{analyze-only}} goal of {{maven-dependency-plugin}} so that dependency
> scopes that are to broad may come to attention while executing the build. In
> addition I find it helpful to activate the maven-enforcer-plugin with the
> rule {{requireExplicitDependencyScope}} so that an explicit scope has to be
> defined for each dependency.
> By doing this, I dicovered the following obsolete dependencies in the JSF
> module:
> {noformat}
> api -> jakarta.el-api (compile)
> impl -> deltaspike-proxy-module-api (compile)
> impl -> xml-apis (test)
> {noformat}
> The following dependencies are used transitively, but are not explicitely
> defined:
> {noformat}
> api -> junit-jupiter-api (test)
> impl -> arquillian-container-test-api (test)
> impl -> arquillian-junit-core (test)
> impl -> arquillian-test-api (test)
> impl -> shrinkwrap-api (test)
> impl -> selenium-api (test)
> impl -> selenium-support (test)
> {noformat}
> The following scopes seem to be too broad:
> {noformat}
> impl -> jakarta.el-api (compile)
> impl -> tomcat-servlet-api (compile)
> {noformat}
> I think we should always declare Jakarta EE APIs as "provided", because an
> Application Server already supplies the correct API version fitting its
> runtime.
> I will supply a PR to show my idea.
> If you like this idea, we could transfer this configuration to other modules.
> The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
> could then be moved up to one of its parents or distributed according to
> modules that inherit dependencies to their children.
> Further questions:
> * Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
> (optional) dependency of {{jsf-impl}} so that it will likely be automatically
> be included in the classpath? Or should it rather not be included by default,
> leaving it up to the consumer?
> * Should compile/provided dependency {{tomcat-servlet-api}} be changed to
> Jakarta Servlet API?
> * Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
> seems to have been used accidentally and only within this single project)?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1474) Inquiry Regarding Potential Inadequate Password-Based Encryption in DefaultCipherService.aesEncrypt (DeltaSpike 1.9.4)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Xia updated DELTASPIKE-1474:
--
Description:
Hey everyone,
I've got a question concerning the aesEncrypt method within
org.apache.deltaspike.core.impl.crypto.DefaultCipherService.aesEncrypt.
This method employs a custom key derivation function:
{code:java}
private SecretKeySpec getSecretKeySpec(String password)
{
byte[] pwdHash = secureHash(password);
byte[] key = Arrays.copyOf(pwdHash, 16); // using only the first 128 bits
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
Here, the function hashes the provided password once to serve as the encryption
key, without utilizing a standard pbkdf api.
{code:java}
protected byte[] secureHash(String value)
{
try
{
MessageDigest md = MessageDigest.getInstance(HASH_ALGORITHM);
return md.digest(value.getBytes(UTF_8));
}
catch (NoSuchAlgorithmException e)
{
throw new RuntimeException(e);
}
}
{code}
However, employing such a low iteration count might not suffice for
contemporary encryption standards. For instance, RFC 8018 suggests a minimum of
1000 iterations for PBE[1]. In 2023, OWASP recommended employing 600,000
iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512[2].
How about utilizing a standard PBKDF with a higher iteration count instead?
Or we can simply use multi-round hash in the secureHash method for better
security
For instance:
{code:java}
private SecretKeySpec getSecretKeySpec(String password, String salt)
{
int iterationCount = 1; // Recommended: at least 10,000 iterations
int keyLength = 128; // utilizing 128-bit AES
KeySpec spec = new PBEKeySpec(password.toCharArray(), salt.getBytes(),
iterationCount, keyLength);
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
byte[] key = factory.generateSecret(spec).getEncoded();
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
[1]["PKCS #5: Password-Based Cryptography Specification, Version
2.0"|http://tools.ietf.org/html/rfc2898#section-5.2]
[2] ["Password Storage Cheat
Sheet"|https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2]
was:
Hey everyone,
I've got a question concerning the aesEncrypt method within
org.apache.deltaspike.core.impl.crypto.DefaultCipherService.aesEncrypt.
This method employs a custom key derivation function:
{code:java}
private SecretKeySpec getSecretKeySpec(String password)
{
byte[] pwdHash = secureHash(password);
byte[] key = Arrays.copyOf(pwdHash, 16); // using only the first 128 bits
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
Here, the function hashes the provided password once to serve as the encryption
key, without utilizing a standard pbkdf api.
{code:java}
protected byte[] c(String value)
{
try
{
MessageDigest md = MessageDigest.getInstance(HASH_ALGORITHM);
return md.digest(value.getBytes(UTF_8));
}
catch (NoSuchAlgorithmException e)
{
throw new RuntimeException(e);
}
}
{code}
However, employing such a low iteration count might not suffice for
contemporary encryption standards. For instance, RFC 8018 suggests a minimum of
1000 iterations for PBE[1]. In 2023, OWASP recommended employing 600,000
iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512[2].
How about utilizing a standard PBKDF with a higher iteration count instead?
Or we can simply use multi-round hash in the secureHash method for better
security
For instance:
{code:java}
private SecretKeySpec getSecretKeySpec(String password, String salt)
{
int iterationCount = 1; // Recommended: at least 10,000 iterations
int keyLength = 128; // utilizing 128-bit AES
KeySpec spec = new PBEKeySpec(password.toCharArray(), salt.getBytes(),
iterationCount, keyLength);
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
byte[] key = factory.generateSecret(spec).getEncoded();
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
[1]["PKCS #5: Password-Based Cryptography Specification, Version
2.0"|http://tools.ietf.org/html/rfc2898#section-5.2]
[2] ["Password Storage Cheat
Sheet"|https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2]
> Inquiry Regarding Potential Inadequate Password-Based Encryption in
> DefaultCipherService.aesEncrypt (DeltaSpike 1.9.4)
> --
>
>
[jira] [Updated] (DELTASPIKE-1474) Inquiry Regarding Potential Inadequate Password-Based Encryption in DefaultCipherService.aesEncrypt (DeltaSpike 1.9.4)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Xia updated DELTASPIKE-1474:
--
Description:
Hey everyone,
I've got a question concerning the aesEncrypt method within
org.apache.deltaspike.core.impl.crypto.DefaultCipherService.aesEncrypt.
This method employs a custom key derivation function:
{code:java}
private SecretKeySpec getSecretKeySpec(String password)
{
byte[] pwdHash = secureHash(password);
byte[] key = Arrays.copyOf(pwdHash, 16); // using only the first 128 bits
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
Here, the function hashes the provided password once to serve as the encryption
key, without utilizing a standard pbkdf api.
{code:java}
protected byte[] c(String value)
{
try
{
MessageDigest md = MessageDigest.getInstance(HASH_ALGORITHM);
return md.digest(value.getBytes(UTF_8));
}
catch (NoSuchAlgorithmException e)
{
throw new RuntimeException(e);
}
}
{code}
However, employing such a low iteration count might not suffice for
contemporary encryption standards. For instance, RFC 8018 suggests a minimum of
1000 iterations for PBE[1]. In 2023, OWASP recommended employing 600,000
iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512[2].
How about utilizing a standard PBKDF with a higher iteration count instead?
Or we can simply use multi-round hash in the secureHash method for better
security
For instance:
{code:java}
private SecretKeySpec getSecretKeySpec(String password, String salt)
{
int iterationCount = 1; // Recommended: at least 10,000 iterations
int keyLength = 128; // utilizing 128-bit AES
KeySpec spec = new PBEKeySpec(password.toCharArray(), salt.getBytes(),
iterationCount, keyLength);
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
byte[] key = factory.generateSecret(spec).getEncoded();
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
[1]["PKCS #5: Password-Based Cryptography Specification, Version
2.0"|http://tools.ietf.org/html/rfc2898#section-5.2]
[2] ["Password Storage Cheat
Sheet"|https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2]
was:
Hey everyone,
I've got a question concerning the aesEncrypt method within
org.apache.deltaspike.core.impl.crypto.DefaultCipherService.aesEncrypt.
This method employs a custom key derivation function:
{code:java}
private SecretKeySpec getSecretKeySpec(String password)
{
byte[] pwdHash = secureHash(password);
byte[] key = Arrays.copyOf(pwdHash, 16); // using only the first 128 bits
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
Here, the function hashes the provided password once to serve as the encryption
key, without utilizing a standard pbkdf api.
{code:java}
protected byte[] c(String value)
{
try
{
MessageDigest md = MessageDigest.getInstance(HASH_ALGORITHM);
return md.digest(value.getBytes(UTF_8));
}
catch (NoSuchAlgorithmException e)
{
throw new RuntimeException(e);
}
}
{code}
However, employing such a low iteration count might not suffice for
contemporary encryption standards. For instance, RFC 8018 suggests a minimum of
1000 iterations for PBE[1]. In 2023, OWASP recommended employing 600,000
iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512[2].
How about utilizing a standard PBKDF with a higher iteration count instead?
Or we can simply use multi-round hash in the secureHash method
For instance:
{code:java}
private SecretKeySpec getSecretKeySpec(String password, String salt)
{
int iterationCount = 1; // Recommended: at least 10,000 iterations
int keyLength = 128; // utilizing 128-bit AES
KeySpec spec = new PBEKeySpec(password.toCharArray(), salt.getBytes(),
iterationCount, keyLength);
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
byte[] key = factory.generateSecret(spec).getEncoded();
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
[1]["PKCS #5: Password-Based Cryptography Specification, Version 2.0"|
http://tools.ietf.org/html/rfc2898#section-5.2]
[2] ["Password Storage Cheat
Sheet"|https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2]
> Inquiry Regarding Potential Inadequate Password-Based Encryption in
> DefaultCipherService.aesEncrypt (DeltaSpike 1.9.4)
> --
>
> Key: DELTAS
[jira] [Updated] (DELTASPIKE-1474) Inquiry Regarding Potential Inadequate Password-Based Encryption in DefaultCipherService.aesEncrypt (DeltaSpike 1.9.4)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Xia updated DELTASPIKE-1474:
--
Description:
Hey everyone,
I've got a question concerning the aesEncrypt method within
org.apache.deltaspike.core.impl.crypto.DefaultCipherService.aesEncrypt.
This method employs a custom key derivation function:
{code:java}
private SecretKeySpec getSecretKeySpec(String password)
{
byte[] pwdHash = secureHash(password);
byte[] key = Arrays.copyOf(pwdHash, 16); // using only the first 128 bits
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
Here, the function hashes the provided password once to serve as the encryption
key, without utilizing a standard pbkdf api.
{code:java}
protected byte[] c(String value)
{
try
{
MessageDigest md = MessageDigest.getInstance(HASH_ALGORITHM);
return md.digest(value.getBytes(UTF_8));
}
catch (NoSuchAlgorithmException e)
{
throw new RuntimeException(e);
}
}
{code}
However, employing such a low iteration count might not suffice for
contemporary encryption standards. For instance, RFC 8018 suggests a minimum of
1000 iterations for PBE[1]. In 2023, OWASP recommended employing 600,000
iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512[2].
How about utilizing a standard PBKDF with a higher iteration count instead?
Or we can simply use multi-round hash in the secureHash method
For instance:
{code:java}
private SecretKeySpec getSecretKeySpec(String password, String salt)
{
int iterationCount = 1; // Recommended: at least 10,000 iterations
int keyLength = 128; // utilizing 128-bit AES
KeySpec spec = new PBEKeySpec(password.toCharArray(), salt.getBytes(),
iterationCount, keyLength);
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
byte[] key = factory.generateSecret(spec).getEncoded();
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
{code}
[1]["PKCS #5: Password-Based Cryptography Specification, Version 2.0"|
http://tools.ietf.org/html/rfc2898#section-5.2]
[2] ["Password Storage Cheat
Sheet"|https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2]
was:
Hey everyone,
I've got a question concerning the aesEncrypt method within
org.apache.deltaspike.core.impl.crypto.DefaultCipherService.aesEncrypt.
This method employs a custom key derivation function:
```java
private SecretKeySpec getSecretKeySpec(String password)
{
byte[] pwdHash = secureHash(password);
byte[] key = Arrays.copyOf(pwdHash, 16); // using only the first 128 bits
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
```
Here, the function hashes the provided password once to serve as the encryption
key, without utilizing a standard pbkdf api.
```java
protected byte[] c(String value)
{
try
{
MessageDigest md = MessageDigest.getInstance(HASH_ALGORITHM);
return md.digest(value.getBytes(UTF_8));
}
catch (NoSuchAlgorithmException e)
{
throw new RuntimeException(e);
}
}
```
However, employing such a low iteration count might not suffice for
contemporary encryption standards. For instance, RFC 8018 suggests a minimum of
1000 iterations for PBE[1]. In 2023, OWASP recommended employing 600,000
iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512[2].
How about utilizing a standard PBKDF with a higher iteration count instead?
Or we can simply use multi-round hash in the secureHash method
For instance:
```java
private SecretKeySpec getSecretKeySpec(String password, String salt)
{
int iterationCount = 1; // Recommended: at least 10,000 iterations
int keyLength = 128; // utilizing 128-bit AES
KeySpec spec = new PBEKeySpec(password.toCharArray(), salt.getBytes(),
iterationCount, keyLength);
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
byte[] key = factory.generateSecret(spec).getEncoded();
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
```
[1][ "PKCS #5: Password-Based Cryptography Specification, Version
2.0"|http://tools.ietf.org/html/rfc2898#section-5.2]
[2] ["Password Storage Cheat
Sheet"|https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2]
> Inquiry Regarding Potential Inadequate Password-Based Encryption in
> DefaultCipherService.aesEncrypt (DeltaSpike 1.9.4)
> --
>
> Key: DELTASPIKE-1474
> URL: ht
[jira] [Created] (DELTASPIKE-1474) Inquiry Regarding Potential Inadequate Password-Based Encryption in DefaultCipherService.aesEncrypt (DeltaSpike 1.9.4)
Yifan Xia created DELTASPIKE-1474:
-
Summary: Inquiry Regarding Potential Inadequate Password-Based
Encryption in DefaultCipherService.aesEncrypt (DeltaSpike 1.9.4)
Key: DELTASPIKE-1474
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1474
Project: DeltaSpike
Issue Type: Improvement
Security Level: public (Regular issues)
Reporter: Yifan Xia
Hey everyone,
I've got a question concerning the aesEncrypt method within
org.apache.deltaspike.core.impl.crypto.DefaultCipherService.aesEncrypt.
This method employs a custom key derivation function:
```java
private SecretKeySpec getSecretKeySpec(String password)
{
byte[] pwdHash = secureHash(password);
byte[] key = Arrays.copyOf(pwdHash, 16); // using only the first 128 bits
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
```
Here, the function hashes the provided password once to serve as the encryption
key, without utilizing a standard pbkdf api.
```java
protected byte[] c(String value)
{
try
{
MessageDigest md = MessageDigest.getInstance(HASH_ALGORITHM);
return md.digest(value.getBytes(UTF_8));
}
catch (NoSuchAlgorithmException e)
{
throw new RuntimeException(e);
}
}
```
However, employing such a low iteration count might not suffice for
contemporary encryption standards. For instance, RFC 8018 suggests a minimum of
1000 iterations for PBE[1]. In 2023, OWASP recommended employing 600,000
iterations for PBKDF2-HMAC-SHA256 and 210,000 for PBKDF2-HMAC-SHA512[2].
How about utilizing a standard PBKDF with a higher iteration count instead?
Or we can simply use multi-round hash in the secureHash method
For instance:
```java
private SecretKeySpec getSecretKeySpec(String password, String salt)
{
int iterationCount = 1; // Recommended: at least 10,000 iterations
int keyLength = 128; // utilizing 128-bit AES
KeySpec spec = new PBEKeySpec(password.toCharArray(), salt.getBytes(),
iterationCount, keyLength);
SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256");
byte[] key = factory.generateSecret(spec).getEncoded();
// Note: utilizing 128-bit AES avoids the necessity for the "Unlimited Crypto"
patch
return new SecretKeySpec(key, "AES");
}
```
[1][ "PKCS #5: Password-Based Cryptography Specification, Version
2.0"|http://tools.ietf.org/html/rfc2898#section-5.2]
[2] ["Password Storage Cheat
Sheet"|https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#pbkdf2]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1473) Improve dependency consistency in JSF module (dependency-analyze + requireExplicitDependencyScope)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Munier updated DELTASPIKE-1473:
-
Description:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze-only}} goal of {{maven-dependency-plugin}} so that dependency scopes
that are to broad may come to attention while executing the build. In addition
I find it helpful to activate the maven-enforcer-plugin with the rule
{{requireExplicitDependencyScope}} so that an explicit scope has to be defined
for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF
module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely
defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an
Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules.
The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
could then be moved up to one of its parents or distributed according to
modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
(optional) dependency of {{jsf-impl}} so that it will likely be automatically
be included in the classpath? Or should it rather not be included by default,
leaving it up to the consumer?
* Should compile/provided dependency {{tomcat-servlet-api}} be changed to
Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
seems to have been used accidentally and only within this single project)?
was:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze-only}} goal of {{maven-dependency-plugin}} so that dependency scopes
that are to broad may come to attention while executing the build. In addition
I find it helpful to activate the maven-enforcer-plugin with the rule
{{requireExplicitDependencyScope}} so that an explicit scope has to be defined
for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF
module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely
defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an
Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules.
The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
could then be moved up to one of its parents or distributed according to
modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
(optional) dependency of {{jsf-impl}} so that it will likely be automatically
be included in the classpath? Or should it rather not be included by default,
leaving it up to the consumer?
* Should compile/provided dependency {{tomcat-servlet-api}} be changed to
Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
seems to have been used accidentally)?
> Improve dependency consistency in JSF module (dependency-analyze +
> requireExplicitDependencyScope)
> --
>
> Key: DELTASPIKE-1473
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1473
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(
[jira] [Updated] (DELTASPIKE-1473) Improve dependency consistency in JSF module (dependency-analyze + requireExplicitDependencyScope)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Munier updated DELTASPIKE-1473:
-
Description:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze-only}} goal of {{maven-dependency-plugin}} so that dependency scopes
that are to broad may come to attention while executing the build. In addition
I find it helpful to activate the maven-enforcer-plugin with the rule
{{requireExplicitDependencyScope}} so that an explicit scope has to be defined
for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF
module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely
defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an
Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules.
The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
could then be moved up to one of its parents or distributed according to
modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
(optional) dependency of {{jsf-impl}} so that it will likely be automatically
be included in the classpath? Or should it rather not be included by default,
leaving it up to the consumer?
* Should dependency {{tomcat-servlet-api}} be changed to Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
seems to have been used accidentally)?
was:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze-only}} goal of {{maven-dependency-plugin}} so that dependency scopes
that are to broad may come to attention while executing the build. In addition
I find it helpful to activate the maven-enforcer-plugin with the rule
{{requireExplicitDependencyScope}} so that an explicit scope has to be defined
for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF
module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely
defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an
Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules.
The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
could then be moved up to one of its parents or distributed according to
modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
(optional) dependency of {{jsf-impl}} so that it will likely be automatically
be included in the classpath?
* Should dependency {{tomcat-servlet-api}} be changed to Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
seems to have been used accidentally)?
> Improve dependency consistency in JSF module (dependency-analyze +
> requireExplicitDependencyScope)
> --
>
> Key: DELTASPIKE-1473
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1473
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Minor
>
[jira] [Updated] (DELTASPIKE-1473) Improve dependency consistency in JSF module (dependency-analyze + requireExplicitDependencyScope)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Munier updated DELTASPIKE-1473:
-
Description:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze-only}} goal of {{maven-dependency-plugin}} so that dependency scopes
that are to broad may come to attention while executing the build. In addition
I find it helpful to activate the maven-enforcer-plugin with the rule
{{requireExplicitDependencyScope}} so that an explicit scope has to be defined
for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF
module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely
defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an
Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules.
The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
could then be moved up to one of its parents or distributed according to
modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
(optional) dependency of {{jsf-impl}} so that it will likely be automatically
be included in the classpath? Or should it rather not be included by default,
leaving it up to the consumer?
* Should compile/provided dependency {{tomcat-servlet-api}} be changed to
Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
seems to have been used accidentally)?
was:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze-only}} goal of {{maven-dependency-plugin}} so that dependency scopes
that are to broad may come to attention while executing the build. In addition
I find it helpful to activate the maven-enforcer-plugin with the rule
{{requireExplicitDependencyScope}} so that an explicit scope has to be defined
for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF
module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely
defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an
Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules.
The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
could then be moved up to one of its parents or distributed according to
modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
(optional) dependency of {{jsf-impl}} so that it will likely be automatically
be included in the classpath? Or should it rather not be included by default,
leaving it up to the consumer?
* Should dependency {{tomcat-servlet-api}} be changed to Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
seems to have been used accidentally)?
> Improve dependency consistency in JSF module (dependency-analyze +
> requireExplicitDependencyScope)
> --
>
> Key: DELTASPIKE-1473
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1473
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: JSF-Module
>Aff
[jira] [Updated] (DELTASPIKE-1473) Improve dependency consistency in JSF module (dependency-analyze + requireExplicitDependencyScope)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Munier updated DELTASPIKE-1473:
-
Description:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze-only}} goal of {{maven-dependency-plugin}} so that dependency scopes
that are to broad may come to attention while executing the build. In addition
I find it helpful to activate the maven-enforcer-plugin with the rule
{{requireExplicitDependencyScope}} so that an explicit scope has to be defined
for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF
module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely
defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an
Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules.
The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
could then be moved up to one of its parents or distributed according to
modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
(optional) dependency of {{jsf-impl}} so that it will likely be automatically
be included in the classpath?
* Should dependency {{tomcat-servlet-api}} be changed to Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
seems to have been used accidentally)?
was:
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze}} goal of {{maven-dependency-plugin}} so that dependency scopes that
are to broad may come to attention while executing the build. In addition I
find it helpful to activate the maven-enforcer-plugin with the rule
{{requireExplicitDependencyScope}} so that an explicit scope has to be defined
for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF
module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely
defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an
Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules.
The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
could then be moved up to one of its parents or distributed according to
modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
(optional) dependency of {{jsf-impl}} so that it will likely be automatically
be included in the classpath?
* Should dependency {{tomcat-servlet-api}} be changed to Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
seems to have been used accidentally)?
> Improve dependency consistency in JSF module (dependency-analyze +
> requireExplicitDependencyScope)
> --
>
> Key: DELTASPIKE-1473
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1473
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining
[jira] [Commented] (DELTASPIKE-1473) Improve dependency consistency in JSF module (dependency-analyze + requireExplicitDependencyScope)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840544#comment-17840544
]
Christian Munier commented on DELTASPIKE-1473:
--
PR created: https://github.com/apache/deltaspike/pull/160
> Improve dependency consistency in JSF module (dependency-analyze +
> requireExplicitDependencyScope)
> --
>
> Key: DELTASPIKE-1473
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1473
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
> {{analyze}} goal of {{maven-dependency-plugin}} so that dependency scopes
> that are to broad may come to attention while executing the build. In
> addition I find it helpful to activate the maven-enforcer-plugin with the
> rule {{requireExplicitDependencyScope}} so that an explicit scope has to be
> defined for each dependency.
> By doing this, I dicovered the following obsolete dependencies in the JSF
> module:
> {noformat}
> api -> jakarta.el-api (compile)
> impl -> deltaspike-proxy-module-api (compile)
> impl -> xml-apis (test)
> {noformat}
> The following dependencies are used transitively, but are not explicitely
> defined:
> {noformat}
> api -> junit-jupiter-api (test)
> impl -> arquillian-container-test-api (test)
> impl -> arquillian-junit-core (test)
> impl -> arquillian-test-api (test)
> impl -> shrinkwrap-api (test)
> impl -> selenium-api (test)
> impl -> selenium-support (test)
> {noformat}
> The following scopes seem to be too broad:
> {noformat}
> impl -> jakarta.el-api (compile)
> impl -> tomcat-servlet-api (compile)
> {noformat}
> I think we should always declare Jakarta EE APIs as "provided", because an
> Application Server already supplies the correct API version fitting its
> runtime.
> I will supply a PR to show my idea.
> If you like this idea, we could transfer this configuration to other modules.
> The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
> could then be moved up to one of its parents or distributed according to
> modules that inherit dependencies to their children.
> Further questions:
> * Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
> (optional) dependency of {{jsf-impl}} so that it will likely be automatically
> be included in the classpath?
> * Should dependency {{tomcat-servlet-api}} be changed to Jakarta Servlet API?
> * Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
> seems to have been used accidentally)?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1473) Improve dependency consistency in JSF module (dependency-analyze + requireExplicitDependencyScope)
[
https://issues.apache.org/jira/browse/DELTASPIKE-1473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Munier updated DELTASPIKE-1473:
-
Labels: pull-request-available (was: )
> Improve dependency consistency in JSF module (dependency-analyze +
> requireExplicitDependencyScope)
> --
>
> Key: DELTASPIKE-1473
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1473
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
> {{analyze}} goal of {{maven-dependency-plugin}} so that dependency scopes
> that are to broad may come to attention while executing the build. In
> addition I find it helpful to activate the maven-enforcer-plugin with the
> rule {{requireExplicitDependencyScope}} so that an explicit scope has to be
> defined for each dependency.
> By doing this, I dicovered the following obsolete dependencies in the JSF
> module:
> {noformat}
> api -> jakarta.el-api (compile)
> impl -> deltaspike-proxy-module-api (compile)
> impl -> xml-apis (test)
> {noformat}
> The following dependencies are used transitively, but are not explicitely
> defined:
> {noformat}
> api -> junit-jupiter-api (test)
> impl -> arquillian-container-test-api (test)
> impl -> arquillian-junit-core (test)
> impl -> arquillian-test-api (test)
> impl -> shrinkwrap-api (test)
> impl -> selenium-api (test)
> impl -> selenium-support (test)
> {noformat}
> The following scopes seem to be too broad:
> {noformat}
> impl -> jakarta.el-api (compile)
> impl -> tomcat-servlet-api (compile)
> {noformat}
> I think we should always declare Jakarta EE APIs as "provided", because an
> Application Server already supplies the correct API version fitting its
> runtime.
> I will supply a PR to show my idea.
> If you like this idea, we could transfer this configuration to other modules.
> The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
> could then be moved up to one of its parents or distributed according to
> modules that inherit dependencies to their children.
> Further questions:
> * Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
> (optional) dependency of {{jsf-impl}} so that it will likely be automatically
> be included in the classpath?
> * Should dependency {{tomcat-servlet-api}} be changed to Jakarta Servlet API?
> * Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
> seems to have been used accidentally)?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DELTASPIKE-1473) Improve dependency consistency in JSF module (dependency-analyze + requireExplicitDependencyScope)
Christian Munier created DELTASPIKE-1473:
Summary: Improve dependency consistency in JSF module
(dependency-analyze + requireExplicitDependencyScope)
Key: DELTASPIKE-1473
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1473
Project: DeltaSpike
Issue Type: Improvement
Security Level: public (Regular issues)
Components: JSF-Module
Affects Versions: 2.0.0
Reporter: Christian Munier
As a follow-up to DELTASPIKE-1472 I think it would be helpful to include the
{{analyze}} goal of {{maven-dependency-plugin}} so that dependency scopes that
are to broad may come to attention while executing the build. In addition I
find it helpful to activate the maven-enforcer-plugin with the rule
{{requireExplicitDependencyScope}} so that an explicit scope has to be defined
for each dependency.
By doing this, I dicovered the following obsolete dependencies in the JSF
module:
{noformat}
api -> jakarta.el-api (compile)
impl -> deltaspike-proxy-module-api (compile)
impl -> xml-apis (test)
{noformat}
The following dependencies are used transitively, but are not explicitely
defined:
{noformat}
api -> junit-jupiter-api (test)
impl -> arquillian-container-test-api (test)
impl -> arquillian-junit-core (test)
impl -> arquillian-test-api (test)
impl -> shrinkwrap-api (test)
impl -> selenium-api (test)
impl -> selenium-support (test)
{noformat}
The following scopes seem to be too broad:
{noformat}
impl -> jakarta.el-api (compile)
impl -> tomcat-servlet-api (compile)
{noformat}
I think we should always declare Jakarta EE APIs as "provided", because an
Application Server already supplies the correct API version fitting its runtime.
I will supply a PR to show my idea.
If you like this idea, we could transfer this configuration to other modules.
The configuration for the {{analyze}} goal of the {{maven-dependency-plugin}}
could then be moved up to one of its parents or distributed according to
modules that inherit dependencies to their children.
Further questions:
* Should dependency {{deltaspike-proxy-module-impl-asm}} be defined as an
(optional) dependency of {{jsf-impl}} so that it will likely be automatically
be included in the classpath?
* Should dependency {{tomcat-servlet-api}} be changed to Jakarta Servlet API?
* Should {{dependency junit-jupiter-api}} be replaced by JUnit Core (since it
seems to have been used accidentally)?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DELTASPIKE-1472) htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
[
https://issues.apache.org/jira/browse/DELTASPIKE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved DELTASPIKE-1472.
---
Resolution: Fixed
> htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
>
>
> Key: DELTASPIKE-1472
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1472
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.0.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Since version 2.0.0, {{deltaspike-jsf-module-impl}} has a compile dependency
> to {{htmlunit3-driver}}.
> This includes a subtree of several other transitive dependencies, including
> Selenium, OpenTelemetry and Jetty Components, which are then also packaged in
> an application (e.g. WAR or EAR) that uses the DeltaSpike JSF Module.
> {noformat}
> +- org.apache.deltaspike.modules:deltaspike-jsf-module-impl:jar:2.0.0:runtime
>\- org.seleniumhq.selenium:htmlunit3-driver:jar:4.18.1:runtime
> +- org.seleniumhq.selenium:selenium-api:jar:4.18.1:runtime
> +- org.seleniumhq.selenium:selenium-support:jar:4.18.1:runtime
> | +- com.google.auto.service:auto-service-annotations:jar:1.1.1:runtime
> | +- org.seleniumhq.selenium:selenium-json:jar:4.18.1:runtime
> | \- org.seleniumhq.selenium:selenium-remote-driver:jar:4.18.1:runtime
> | +-
> io.opentelemetry.semconv:opentelemetry-semconv:jar:1.23.1-alpha:runtime
> | +- io.opentelemetry:opentelemetry-api:jar:1.35.0:runtime
> | +- io.opentelemetry:opentelemetry-context:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-exporter-logging:jar:1.35.0:runtime
> | +- io.opentelemetry:opentelemetry-sdk-common:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure-spi:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure:jar:1.35.0:runtime
> | | \-
> io.opentelemetry:opentelemetry-api-events:jar:1.35.0-alpha:runtime
> | +- io.opentelemetry:opentelemetry-sdk-trace:jar:1.35.0:runtime
> | | \-
> io.opentelemetry:opentelemetry-extension-incubator:jar:1.35.0-alpha:runtime
> | +- io.opentelemetry:opentelemetry-sdk:jar:1.35.0:runtime
> | | +-
> io.opentelemetry:opentelemetry-sdk-metrics:jar:1.35.0:runtime
> | | \- io.opentelemetry:opentelemetry-sdk-logs:jar:1.35.0:runtime
> | +- org.seleniumhq.selenium:selenium-http:jar:4.18.1:runtime
> | | \- dev.failsafe:failsafe:jar:3.3.2:runtime
> | +- org.seleniumhq.selenium:selenium-manager:jar:4.18.1:runtime
> | \- org.seleniumhq.selenium:selenium-os:jar:4.18.1:runtime
> |\- org.apache.commons:commons-exec:jar:1.3:runtime
> \- org.htmlunit:htmlunit:jar:3.11.0:runtime
> +- org.apache.httpcomponents:httpmime:jar:4.5.14:runtime
> | \- org.apache.httpcomponents:httpclient:jar:4.5.14:runtime
> | \- org.apache.httpcomponents:httpcore:jar:4.4.16:runtime
> +- org.htmlunit:htmlunit-core-js:jar:3.11.0:runtime
> +- org.htmlunit:neko-htmlunit:jar:3.11.2:runtime
> +- org.htmlunit:htmlunit-cssparser:jar:3.11.0:runtime
> +- org.htmlunit:htmlunit-xpath:jar:3.11.0:runtime
> +- org.htmlunit:htmlunit-csp:jar:3.11.0:runtime
> +- commons-io:commons-io:jar:2.15.0:runtime
> +- commons-logging:commons-logging:jar:1.3.0:runtime
> +- commons-net:commons-net:jar:3.10.0:runtime
> +- commons-codec:commons-codec:jar:1.16.1:runtime
> +- org.brotli:dec:jar:0.1.2:runtime
> \-
> org.eclipse.jetty.websocket:websocket-client:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-client:jar:9.4.53.v20231009:runtime
> | \- org.eclipse.jetty:jetty-http:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-util:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-io:jar:9.4.53.v20231009:runtime
> \-
> org.eclipse.jetty.websocket:websocket-common:jar:9.4.53.v20231009:runtime
>\-
> org.eclipse.jetty.websocket:websocket-api:jar:9.4.53.v20231009:runtime
> {noformat}
> h3. Workaround
> {{htmlunit3-driver}} and the transitive depend
[jira] [Updated] (DELTASPIKE-1472) htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
[
https://issues.apache.org/jira/browse/DELTASPIKE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko updated DELTASPIKE-1472:
--
Fix Version/s: 2.0.1
> htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
>
>
> Key: DELTASPIKE-1472
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1472
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Major
> Labels: pull-request-available
> Fix For: 2.0.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Since version 2.0.0, {{deltaspike-jsf-module-impl}} has a compile dependency
> to {{htmlunit3-driver}}.
> This includes a subtree of several other transitive dependencies, including
> Selenium, OpenTelemetry and Jetty Components, which are then also packaged in
> an application (e.g. WAR or EAR) that uses the DeltaSpike JSF Module.
> {noformat}
> +- org.apache.deltaspike.modules:deltaspike-jsf-module-impl:jar:2.0.0:runtime
>\- org.seleniumhq.selenium:htmlunit3-driver:jar:4.18.1:runtime
> +- org.seleniumhq.selenium:selenium-api:jar:4.18.1:runtime
> +- org.seleniumhq.selenium:selenium-support:jar:4.18.1:runtime
> | +- com.google.auto.service:auto-service-annotations:jar:1.1.1:runtime
> | +- org.seleniumhq.selenium:selenium-json:jar:4.18.1:runtime
> | \- org.seleniumhq.selenium:selenium-remote-driver:jar:4.18.1:runtime
> | +-
> io.opentelemetry.semconv:opentelemetry-semconv:jar:1.23.1-alpha:runtime
> | +- io.opentelemetry:opentelemetry-api:jar:1.35.0:runtime
> | +- io.opentelemetry:opentelemetry-context:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-exporter-logging:jar:1.35.0:runtime
> | +- io.opentelemetry:opentelemetry-sdk-common:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure-spi:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure:jar:1.35.0:runtime
> | | \-
> io.opentelemetry:opentelemetry-api-events:jar:1.35.0-alpha:runtime
> | +- io.opentelemetry:opentelemetry-sdk-trace:jar:1.35.0:runtime
> | | \-
> io.opentelemetry:opentelemetry-extension-incubator:jar:1.35.0-alpha:runtime
> | +- io.opentelemetry:opentelemetry-sdk:jar:1.35.0:runtime
> | | +-
> io.opentelemetry:opentelemetry-sdk-metrics:jar:1.35.0:runtime
> | | \- io.opentelemetry:opentelemetry-sdk-logs:jar:1.35.0:runtime
> | +- org.seleniumhq.selenium:selenium-http:jar:4.18.1:runtime
> | | \- dev.failsafe:failsafe:jar:3.3.2:runtime
> | +- org.seleniumhq.selenium:selenium-manager:jar:4.18.1:runtime
> | \- org.seleniumhq.selenium:selenium-os:jar:4.18.1:runtime
> |\- org.apache.commons:commons-exec:jar:1.3:runtime
> \- org.htmlunit:htmlunit:jar:3.11.0:runtime
> +- org.apache.httpcomponents:httpmime:jar:4.5.14:runtime
> | \- org.apache.httpcomponents:httpclient:jar:4.5.14:runtime
> | \- org.apache.httpcomponents:httpcore:jar:4.4.16:runtime
> +- org.htmlunit:htmlunit-core-js:jar:3.11.0:runtime
> +- org.htmlunit:neko-htmlunit:jar:3.11.2:runtime
> +- org.htmlunit:htmlunit-cssparser:jar:3.11.0:runtime
> +- org.htmlunit:htmlunit-xpath:jar:3.11.0:runtime
> +- org.htmlunit:htmlunit-csp:jar:3.11.0:runtime
> +- commons-io:commons-io:jar:2.15.0:runtime
> +- commons-logging:commons-logging:jar:1.3.0:runtime
> +- commons-net:commons-net:jar:3.10.0:runtime
> +- commons-codec:commons-codec:jar:1.16.1:runtime
> +- org.brotli:dec:jar:0.1.2:runtime
> \-
> org.eclipse.jetty.websocket:websocket-client:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-client:jar:9.4.53.v20231009:runtime
> | \- org.eclipse.jetty:jetty-http:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-util:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-io:jar:9.4.53.v20231009:runtime
> \-
> org.eclipse.jetty.websocket:websocket-common:jar:9.4.53.v20231009:runtime
>\-
> org.eclipse.jetty.websocket:websocket-api:jar:9.4.53.v20231009:runtime
> {noformat}
> h3. Workaround
> {{htmlunit3-driver}} and the transitive depend
[jira] [Commented] (DELTASPIKE-1472) htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
[
https://issues.apache.org/jira/browse/DELTASPIKE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839112#comment-17839112
]
ASF subversion and git services commented on DELTASPIKE-1472:
-
Commit 9a53cc95f6e2d5f2839d16685376c43482773d45 in deltaspike's branch
refs/heads/master from Thomas Andraschko
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=9a53cc95f ]
Merge pull request #159 from cmunier/DELTASPIKE-1472
DELTASPIKE-1472: Fixed: htmlunit3 dependency of deltaspike-jsf-module-impl has
compile scope
> htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
>
>
> Key: DELTASPIKE-1472
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1472
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Since version 2.0.0, {{deltaspike-jsf-module-impl}} has a compile dependency
> to {{htmlunit3-driver}}.
> This includes a subtree of several other transitive dependencies, including
> Selenium, OpenTelemetry and Jetty Components, which are then also packaged in
> an application (e.g. WAR or EAR) that uses the DeltaSpike JSF Module.
> {noformat}
> +- org.apache.deltaspike.modules:deltaspike-jsf-module-impl:jar:2.0.0:runtime
>\- org.seleniumhq.selenium:htmlunit3-driver:jar:4.18.1:runtime
> +- org.seleniumhq.selenium:selenium-api:jar:4.18.1:runtime
> +- org.seleniumhq.selenium:selenium-support:jar:4.18.1:runtime
> | +- com.google.auto.service:auto-service-annotations:jar:1.1.1:runtime
> | +- org.seleniumhq.selenium:selenium-json:jar:4.18.1:runtime
> | \- org.seleniumhq.selenium:selenium-remote-driver:jar:4.18.1:runtime
> | +-
> io.opentelemetry.semconv:opentelemetry-semconv:jar:1.23.1-alpha:runtime
> | +- io.opentelemetry:opentelemetry-api:jar:1.35.0:runtime
> | +- io.opentelemetry:opentelemetry-context:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-exporter-logging:jar:1.35.0:runtime
> | +- io.opentelemetry:opentelemetry-sdk-common:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure-spi:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure:jar:1.35.0:runtime
> | | \-
> io.opentelemetry:opentelemetry-api-events:jar:1.35.0-alpha:runtime
> | +- io.opentelemetry:opentelemetry-sdk-trace:jar:1.35.0:runtime
> | | \-
> io.opentelemetry:opentelemetry-extension-incubator:jar:1.35.0-alpha:runtime
> | +- io.opentelemetry:opentelemetry-sdk:jar:1.35.0:runtime
> | | +-
> io.opentelemetry:opentelemetry-sdk-metrics:jar:1.35.0:runtime
> | | \- io.opentelemetry:opentelemetry-sdk-logs:jar:1.35.0:runtime
> | +- org.seleniumhq.selenium:selenium-http:jar:4.18.1:runtime
> | | \- dev.failsafe:failsafe:jar:3.3.2:runtime
> | +- org.seleniumhq.selenium:selenium-manager:jar:4.18.1:runtime
> | \- org.seleniumhq.selenium:selenium-os:jar:4.18.1:runtime
> |\- org.apache.commons:commons-exec:jar:1.3:runtime
> \- org.htmlunit:htmlunit:jar:3.11.0:runtime
> +- org.apache.httpcomponents:httpmime:jar:4.5.14:runtime
> | \- org.apache.httpcomponents:httpclient:jar:4.5.14:runtime
> | \- org.apache.httpcomponents:httpcore:jar:4.4.16:runtime
> +- org.htmlunit:htmlunit-core-js:jar:3.11.0:runtime
> +- org.htmlunit:neko-htmlunit:jar:3.11.2:runtime
> +- org.htmlunit:htmlunit-cssparser:jar:3.11.0:runtime
> +- org.htmlunit:htmlunit-xpath:jar:3.11.0:runtime
> +- org.htmlunit:htmlunit-csp:jar:3.11.0:runtime
> +- commons-io:commons-io:jar:2.15.0:runtime
> +- commons-logging:commons-logging:jar:1.3.0:runtime
> +- commons-net:commons-net:jar:3.10.0:runtime
> +- commons-codec:commons-codec:jar:1.16.1:runtime
> +- org.brotli:dec:jar:0.1.2:runtime
> \-
> org.eclipse.jetty.websocket:websocket-client:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-client:jar:9.4.53.v20231009:runtime
> | \- org.eclipse.jetty:jetty-http:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-util:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jet
[jira] [Commented] (DELTASPIKE-1472) htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
[
https://issues.apache.org/jira/browse/DELTASPIKE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839111#comment-17839111
]
ASF subversion and git services commented on DELTASPIKE-1472:
-
Commit e71ddfa8855de9991e63989b1a1b34a0221a0d8f in deltaspike's branch
refs/heads/master from Christian Munier
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=e71ddfa88 ]
DELTASPIKE-1472: Changed scope of htmlunit3-driver dependency of
deltaspike-jsf-module-impl from "compile" to "test" so that the resulting tree
of transitive dependencies is not included in runtime.
> htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
>
>
> Key: DELTASPIKE-1472
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1472
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Since version 2.0.0, {{deltaspike-jsf-module-impl}} has a compile dependency
> to {{htmlunit3-driver}}.
> This includes a subtree of several other transitive dependencies, including
> Selenium, OpenTelemetry and Jetty Components, which are then also packaged in
> an application (e.g. WAR or EAR) that uses the DeltaSpike JSF Module.
> {noformat}
> +- org.apache.deltaspike.modules:deltaspike-jsf-module-impl:jar:2.0.0:runtime
>\- org.seleniumhq.selenium:htmlunit3-driver:jar:4.18.1:runtime
> +- org.seleniumhq.selenium:selenium-api:jar:4.18.1:runtime
> +- org.seleniumhq.selenium:selenium-support:jar:4.18.1:runtime
> | +- com.google.auto.service:auto-service-annotations:jar:1.1.1:runtime
> | +- org.seleniumhq.selenium:selenium-json:jar:4.18.1:runtime
> | \- org.seleniumhq.selenium:selenium-remote-driver:jar:4.18.1:runtime
> | +-
> io.opentelemetry.semconv:opentelemetry-semconv:jar:1.23.1-alpha:runtime
> | +- io.opentelemetry:opentelemetry-api:jar:1.35.0:runtime
> | +- io.opentelemetry:opentelemetry-context:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-exporter-logging:jar:1.35.0:runtime
> | +- io.opentelemetry:opentelemetry-sdk-common:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure-spi:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure:jar:1.35.0:runtime
> | | \-
> io.opentelemetry:opentelemetry-api-events:jar:1.35.0-alpha:runtime
> | +- io.opentelemetry:opentelemetry-sdk-trace:jar:1.35.0:runtime
> | | \-
> io.opentelemetry:opentelemetry-extension-incubator:jar:1.35.0-alpha:runtime
> | +- io.opentelemetry:opentelemetry-sdk:jar:1.35.0:runtime
> | | +-
> io.opentelemetry:opentelemetry-sdk-metrics:jar:1.35.0:runtime
> | | \- io.opentelemetry:opentelemetry-sdk-logs:jar:1.35.0:runtime
> | +- org.seleniumhq.selenium:selenium-http:jar:4.18.1:runtime
> | | \- dev.failsafe:failsafe:jar:3.3.2:runtime
> | +- org.seleniumhq.selenium:selenium-manager:jar:4.18.1:runtime
> | \- org.seleniumhq.selenium:selenium-os:jar:4.18.1:runtime
> |\- org.apache.commons:commons-exec:jar:1.3:runtime
> \- org.htmlunit:htmlunit:jar:3.11.0:runtime
> +- org.apache.httpcomponents:httpmime:jar:4.5.14:runtime
> | \- org.apache.httpcomponents:httpclient:jar:4.5.14:runtime
> | \- org.apache.httpcomponents:httpcore:jar:4.4.16:runtime
> +- org.htmlunit:htmlunit-core-js:jar:3.11.0:runtime
> +- org.htmlunit:neko-htmlunit:jar:3.11.2:runtime
> +- org.htmlunit:htmlunit-cssparser:jar:3.11.0:runtime
> +- org.htmlunit:htmlunit-xpath:jar:3.11.0:runtime
> +- org.htmlunit:htmlunit-csp:jar:3.11.0:runtime
> +- commons-io:commons-io:jar:2.15.0:runtime
> +- commons-logging:commons-logging:jar:1.3.0:runtime
> +- commons-net:commons-net:jar:3.10.0:runtime
> +- commons-codec:commons-codec:jar:1.16.1:runtime
> +- org.brotli:dec:jar:0.1.2:runtime
> \-
> org.eclipse.jetty.websocket:websocket-client:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-client:jar:9.4.53.v20231009:runtime
> | \- org.eclipse.jetty:jetty-http:jar:9.4.53.v20231009:runtime
>
[jira] [Commented] (DELTASPIKE-1472) htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
[
https://issues.apache.org/jira/browse/DELTASPIKE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839108#comment-17839108
]
Christian Munier commented on DELTASPIKE-1472:
--
PR created: https://github.com/apache/deltaspike/pull/159
> htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
>
>
> Key: DELTASPIKE-1472
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1472
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since version 2.0.0, {{deltaspike-jsf-module-impl}} has a compile dependency
> to {{htmlunit3-driver}}.
> This includes a subtree of several other transitive dependencies, including
> Selenium, OpenTelemetry and Jetty Components, which are then also packaged in
> an application (e.g. WAR or EAR) that uses the DeltaSpike JSF Module.
> {noformat}
> +- org.apache.deltaspike.modules:deltaspike-jsf-module-impl:jar:2.0.0:runtime
>\- org.seleniumhq.selenium:htmlunit3-driver:jar:4.18.1:runtime
> +- org.seleniumhq.selenium:selenium-api:jar:4.18.1:runtime
> +- org.seleniumhq.selenium:selenium-support:jar:4.18.1:runtime
> | +- com.google.auto.service:auto-service-annotations:jar:1.1.1:runtime
> | +- org.seleniumhq.selenium:selenium-json:jar:4.18.1:runtime
> | \- org.seleniumhq.selenium:selenium-remote-driver:jar:4.18.1:runtime
> | +-
> io.opentelemetry.semconv:opentelemetry-semconv:jar:1.23.1-alpha:runtime
> | +- io.opentelemetry:opentelemetry-api:jar:1.35.0:runtime
> | +- io.opentelemetry:opentelemetry-context:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-exporter-logging:jar:1.35.0:runtime
> | +- io.opentelemetry:opentelemetry-sdk-common:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure-spi:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure:jar:1.35.0:runtime
> | | \-
> io.opentelemetry:opentelemetry-api-events:jar:1.35.0-alpha:runtime
> | +- io.opentelemetry:opentelemetry-sdk-trace:jar:1.35.0:runtime
> | | \-
> io.opentelemetry:opentelemetry-extension-incubator:jar:1.35.0-alpha:runtime
> | +- io.opentelemetry:opentelemetry-sdk:jar:1.35.0:runtime
> | | +-
> io.opentelemetry:opentelemetry-sdk-metrics:jar:1.35.0:runtime
> | | \- io.opentelemetry:opentelemetry-sdk-logs:jar:1.35.0:runtime
> | +- org.seleniumhq.selenium:selenium-http:jar:4.18.1:runtime
> | | \- dev.failsafe:failsafe:jar:3.3.2:runtime
> | +- org.seleniumhq.selenium:selenium-manager:jar:4.18.1:runtime
> | \- org.seleniumhq.selenium:selenium-os:jar:4.18.1:runtime
> |\- org.apache.commons:commons-exec:jar:1.3:runtime
> \- org.htmlunit:htmlunit:jar:3.11.0:runtime
> +- org.apache.httpcomponents:httpmime:jar:4.5.14:runtime
> | \- org.apache.httpcomponents:httpclient:jar:4.5.14:runtime
> | \- org.apache.httpcomponents:httpcore:jar:4.4.16:runtime
> +- org.htmlunit:htmlunit-core-js:jar:3.11.0:runtime
> +- org.htmlunit:neko-htmlunit:jar:3.11.2:runtime
> +- org.htmlunit:htmlunit-cssparser:jar:3.11.0:runtime
> +- org.htmlunit:htmlunit-xpath:jar:3.11.0:runtime
> +- org.htmlunit:htmlunit-csp:jar:3.11.0:runtime
> +- commons-io:commons-io:jar:2.15.0:runtime
> +- commons-logging:commons-logging:jar:1.3.0:runtime
> +- commons-net:commons-net:jar:3.10.0:runtime
> +- commons-codec:commons-codec:jar:1.16.1:runtime
> +- org.brotli:dec:jar:0.1.2:runtime
> \-
> org.eclipse.jetty.websocket:websocket-client:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-client:jar:9.4.53.v20231009:runtime
> | \- org.eclipse.jetty:jetty-http:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-util:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-io:jar:9.4.53.v20231009:runtime
> \-
> org.eclipse.jetty.websocket:websocket-common:jar:9.4.53.v20231009:runtime
>\-
> org.eclipse.jetty.websocket:websocket-api:jar:9.4.53.v20231009:runtime
> {noformat}
>
[jira] [Updated] (DELTASPIKE-1472) htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
[
https://issues.apache.org/jira/browse/DELTASPIKE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Munier updated DELTASPIKE-1472:
-
Labels: pull-request-available (was: )
> htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
>
>
> Key: DELTASPIKE-1472
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1472
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: JSF-Module
>Affects Versions: 2.0.0
>Reporter: Christian Munier
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since version 2.0.0, {{deltaspike-jsf-module-impl}} has a compile dependency
> to {{htmlunit3-driver}}.
> This includes a subtree of several other transitive dependencies, including
> Selenium, OpenTelemetry and Jetty Components, which are then also packaged in
> an application (e.g. WAR or EAR) that uses the DeltaSpike JSF Module.
> {noformat}
> +- org.apache.deltaspike.modules:deltaspike-jsf-module-impl:jar:2.0.0:runtime
>\- org.seleniumhq.selenium:htmlunit3-driver:jar:4.18.1:runtime
> +- org.seleniumhq.selenium:selenium-api:jar:4.18.1:runtime
> +- org.seleniumhq.selenium:selenium-support:jar:4.18.1:runtime
> | +- com.google.auto.service:auto-service-annotations:jar:1.1.1:runtime
> | +- org.seleniumhq.selenium:selenium-json:jar:4.18.1:runtime
> | \- org.seleniumhq.selenium:selenium-remote-driver:jar:4.18.1:runtime
> | +-
> io.opentelemetry.semconv:opentelemetry-semconv:jar:1.23.1-alpha:runtime
> | +- io.opentelemetry:opentelemetry-api:jar:1.35.0:runtime
> | +- io.opentelemetry:opentelemetry-context:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-exporter-logging:jar:1.35.0:runtime
> | +- io.opentelemetry:opentelemetry-sdk-common:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure-spi:jar:1.35.0:runtime
> | +-
> io.opentelemetry:opentelemetry-sdk-extension-autoconfigure:jar:1.35.0:runtime
> | | \-
> io.opentelemetry:opentelemetry-api-events:jar:1.35.0-alpha:runtime
> | +- io.opentelemetry:opentelemetry-sdk-trace:jar:1.35.0:runtime
> | | \-
> io.opentelemetry:opentelemetry-extension-incubator:jar:1.35.0-alpha:runtime
> | +- io.opentelemetry:opentelemetry-sdk:jar:1.35.0:runtime
> | | +-
> io.opentelemetry:opentelemetry-sdk-metrics:jar:1.35.0:runtime
> | | \- io.opentelemetry:opentelemetry-sdk-logs:jar:1.35.0:runtime
> | +- org.seleniumhq.selenium:selenium-http:jar:4.18.1:runtime
> | | \- dev.failsafe:failsafe:jar:3.3.2:runtime
> | +- org.seleniumhq.selenium:selenium-manager:jar:4.18.1:runtime
> | \- org.seleniumhq.selenium:selenium-os:jar:4.18.1:runtime
> |\- org.apache.commons:commons-exec:jar:1.3:runtime
> \- org.htmlunit:htmlunit:jar:3.11.0:runtime
> +- org.apache.httpcomponents:httpmime:jar:4.5.14:runtime
> | \- org.apache.httpcomponents:httpclient:jar:4.5.14:runtime
> | \- org.apache.httpcomponents:httpcore:jar:4.4.16:runtime
> +- org.htmlunit:htmlunit-core-js:jar:3.11.0:runtime
> +- org.htmlunit:neko-htmlunit:jar:3.11.2:runtime
> +- org.htmlunit:htmlunit-cssparser:jar:3.11.0:runtime
> +- org.htmlunit:htmlunit-xpath:jar:3.11.0:runtime
> +- org.htmlunit:htmlunit-csp:jar:3.11.0:runtime
> +- commons-io:commons-io:jar:2.15.0:runtime
> +- commons-logging:commons-logging:jar:1.3.0:runtime
> +- commons-net:commons-net:jar:3.10.0:runtime
> +- commons-codec:commons-codec:jar:1.16.1:runtime
> +- org.brotli:dec:jar:0.1.2:runtime
> \-
> org.eclipse.jetty.websocket:websocket-client:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-client:jar:9.4.53.v20231009:runtime
> | \- org.eclipse.jetty:jetty-http:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-util:jar:9.4.53.v20231009:runtime
> +- org.eclipse.jetty:jetty-io:jar:9.4.53.v20231009:runtime
> \-
> org.eclipse.jetty.websocket:websocket-common:jar:9.4.53.v20231009:runtime
>\-
> org.eclipse.jetty.websocket:websocket-api:jar:9.4.53.v20231009:runtime
> {noformat}
> h3. Workaround
> {{htmlunit3-driver}} and the transitive dependency tree can be exluded via
> Dependency M
[jira] [Created] (DELTASPIKE-1472) htmlunit3 dependency of deltaspike-jsf-module-impl has compile scope
Christian Munier created DELTASPIKE-1472:
Summary: htmlunit3 dependency of deltaspike-jsf-module-impl has
compile scope
Key: DELTASPIKE-1472
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1472
Project: DeltaSpike
Issue Type: Bug
Security Level: public (Regular issues)
Components: JSF-Module
Affects Versions: 2.0.0
Reporter: Christian Munier
Since version 2.0.0, {{deltaspike-jsf-module-impl}} has a compile dependency to
{{htmlunit3-driver}}.
This includes a subtree of several other transitive dependencies, including
Selenium, OpenTelemetry and Jetty Components, which are then also packaged in
an application (e.g. WAR or EAR) that uses the DeltaSpike JSF Module.
{noformat}
+- org.apache.deltaspike.modules:deltaspike-jsf-module-impl:jar:2.0.0:runtime
\- org.seleniumhq.selenium:htmlunit3-driver:jar:4.18.1:runtime
+- org.seleniumhq.selenium:selenium-api:jar:4.18.1:runtime
+- org.seleniumhq.selenium:selenium-support:jar:4.18.1:runtime
| +- com.google.auto.service:auto-service-annotations:jar:1.1.1:runtime
| +- org.seleniumhq.selenium:selenium-json:jar:4.18.1:runtime
| \- org.seleniumhq.selenium:selenium-remote-driver:jar:4.18.1:runtime
| +-
io.opentelemetry.semconv:opentelemetry-semconv:jar:1.23.1-alpha:runtime
| +- io.opentelemetry:opentelemetry-api:jar:1.35.0:runtime
| +- io.opentelemetry:opentelemetry-context:jar:1.35.0:runtime
| +-
io.opentelemetry:opentelemetry-exporter-logging:jar:1.35.0:runtime
| +- io.opentelemetry:opentelemetry-sdk-common:jar:1.35.0:runtime
| +-
io.opentelemetry:opentelemetry-sdk-extension-autoconfigure-spi:jar:1.35.0:runtime
| +-
io.opentelemetry:opentelemetry-sdk-extension-autoconfigure:jar:1.35.0:runtime
| | \-
io.opentelemetry:opentelemetry-api-events:jar:1.35.0-alpha:runtime
| +- io.opentelemetry:opentelemetry-sdk-trace:jar:1.35.0:runtime
| | \-
io.opentelemetry:opentelemetry-extension-incubator:jar:1.35.0-alpha:runtime
| +- io.opentelemetry:opentelemetry-sdk:jar:1.35.0:runtime
| | +- io.opentelemetry:opentelemetry-sdk-metrics:jar:1.35.0:runtime
| | \- io.opentelemetry:opentelemetry-sdk-logs:jar:1.35.0:runtime
| +- org.seleniumhq.selenium:selenium-http:jar:4.18.1:runtime
| | \- dev.failsafe:failsafe:jar:3.3.2:runtime
| +- org.seleniumhq.selenium:selenium-manager:jar:4.18.1:runtime
| \- org.seleniumhq.selenium:selenium-os:jar:4.18.1:runtime
|\- org.apache.commons:commons-exec:jar:1.3:runtime
\- org.htmlunit:htmlunit:jar:3.11.0:runtime
+- org.apache.httpcomponents:httpmime:jar:4.5.14:runtime
| \- org.apache.httpcomponents:httpclient:jar:4.5.14:runtime
| \- org.apache.httpcomponents:httpcore:jar:4.4.16:runtime
+- org.htmlunit:htmlunit-core-js:jar:3.11.0:runtime
+- org.htmlunit:neko-htmlunit:jar:3.11.2:runtime
+- org.htmlunit:htmlunit-cssparser:jar:3.11.0:runtime
+- org.htmlunit:htmlunit-xpath:jar:3.11.0:runtime
+- org.htmlunit:htmlunit-csp:jar:3.11.0:runtime
+- commons-io:commons-io:jar:2.15.0:runtime
+- commons-logging:commons-logging:jar:1.3.0:runtime
+- commons-net:commons-net:jar:3.10.0:runtime
+- commons-codec:commons-codec:jar:1.16.1:runtime
+- org.brotli:dec:jar:0.1.2:runtime
\-
org.eclipse.jetty.websocket:websocket-client:jar:9.4.53.v20231009:runtime
+- org.eclipse.jetty:jetty-client:jar:9.4.53.v20231009:runtime
| \- org.eclipse.jetty:jetty-http:jar:9.4.53.v20231009:runtime
+- org.eclipse.jetty:jetty-util:jar:9.4.53.v20231009:runtime
+- org.eclipse.jetty:jetty-io:jar:9.4.53.v20231009:runtime
\-
org.eclipse.jetty.websocket:websocket-common:jar:9.4.53.v20231009:runtime
\-
org.eclipse.jetty.websocket:websocket-api:jar:9.4.53.v20231009:runtime
{noformat}
h3. Workaround
{{htmlunit3-driver}} and the transitive dependency tree can be exluded via
Dependency Management or while declaring the dependency in the consumer POM.
{noformat}
deltaspike-jsf-module-impl
runtime
org.seleniumhq.selenium
htmlunit3-driver
{noformat}
h3. Proposed solution
The scope of the {{htmlunit3-driver}} dependency should be changed to {{test}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1264) Remove portions of BeanProvider/BeanManagerProvider
[ https://issues.apache.org/jira/browse/DELTASPIKE-1264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated DELTASPIKE-1264: -- Fix Version/s: 2.0.1 (was: 2.0.0) > Remove portions of BeanProvider/BeanManagerProvider > --- > > Key: DELTASPIKE-1264 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1264 > Project: DeltaSpike > Issue Type: Improvement >Reporter: John D. Ament >Assignee: Mark Struberg >Priority: Major > Fix For: 2.0.1 > > > These internal utilities may not be needed based on CDI.current() from CDI > 1.1. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DELTASPIKE-1206) support for CDI 2.0 feature
[ https://issues.apache.org/jira/browse/DELTASPIKE-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved DELTASPIKE-1206. --- Resolution: Fixed Finally activated the feature in our beans.xml in DS 2.0.0. This will speed up class parsing and bring down mem consumption a bit. > support for CDI 2.0 feature > --- > > Key: DELTASPIKE-1206 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1206 > Project: DeltaSpike > Issue Type: Test >Affects Versions: 1.7.1 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 2.0.0 > > > CDI 2.0 will add support for only picking up beans with an explicit scope > annotation. This reduced the memory footprint while also speeding up the > bootstrapping. > See https://issues.jboss.org/browse/CDI-420 > We should add this annotation to our beans.xml and verify that we still work. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1457) Improve Config Interface
[
https://issues.apache.org/jira/browse/DELTASPIKE-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated DELTASPIKE-1457:
--
Fix Version/s: 2.0.1
(was: 2.0.0)
> Improve Config Interface
>
>
> Key: DELTASPIKE-1457
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1457
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Configuration
>Affects Versions: 1.9.6
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.1
>
>
> We should gradually improve our Config Interface, e.g. move
> {{getAllProperties}} over, introduce more type handling, automatic (implicit)
> Converters, etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DELTASPIKE-1437) DeltaSpike-2.0 umbrella ticket
[ https://issues.apache.org/jira/browse/DELTASPIKE-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved DELTASPIKE-1437. --- Assignee: Mark Struberg Resolution: Fixed > DeltaSpike-2.0 umbrella ticket > -- > > Key: DELTASPIKE-1437 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1437 > Project: DeltaSpike > Issue Type: Task > Security Level: public(Regular issues) >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 2.0.0 > > > This is an umbrella ticket for various DeltaSpike 2.0 tasks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1455) Allow to pass properties to Weld
[ https://issues.apache.org/jira/browse/DELTASPIKE-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated DELTASPIKE-1455: -- Fix Version/s: 2.0.0 (was: 1.9.7) > Allow to pass properties to Weld > > > Key: DELTASPIKE-1455 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1455 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: CdiControl >Affects Versions: 1.9.6 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > Fix For: 2.0.0 > > > See PR > https://github.com/apache/deltaspike/pull/129 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DELTASPIKE-1460) Move outdated APIs
[ https://issues.apache.org/jira/browse/DELTASPIKE-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg resolved DELTASPIKE-1460. --- Resolution: Fixed > Move outdated APIs > -- > > Key: DELTASPIKE-1460 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1460 > Project: DeltaSpike > Issue Type: Sub-task > Security Level: public(Regular issues) >Reporter: Gerhard Petracek >Assignee: Gerhard Petracek >Priority: Major > Fix For: 2.0.0 > > > some parts of the api aren't needed with cdi 2.0+ > therefore that parts should be moved until they get removed completely. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1456) Introduce default methods for some functions in ConfigSource
[
https://issues.apache.org/jira/browse/DELTASPIKE-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated DELTASPIKE-1456:
--
Fix Version/s: 2.0.0
(was: 1.9.7)
> Introduce default methods for some functions in ConfigSource
>
>
> Key: DELTASPIKE-1456
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1456
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Configuration
>Affects Versions: 1.9.6
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.0
>
>
> Right now our {{ConfigSource}} interface is still mostly an old Java6
> interface. We already use a default method for the onChange callback
> registration. We could also provide some other default methods, e.g. for
> {{getOrdinal()}} and {{isScannable().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1457) Improve Config Interface
[
https://issues.apache.org/jira/browse/DELTASPIKE-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated DELTASPIKE-1457:
--
Fix Version/s: 2.0.0
(was: 1.9.7)
> Improve Config Interface
>
>
> Key: DELTASPIKE-1457
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1457
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Configuration
>Affects Versions: 1.9.6
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0.0
>
>
> We should gradually improve our Config Interface, e.g. move
> {{getAllProperties}} over, introduce more type handling, automatic (implicit)
> Converters, etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1458) DefaultConfigSourceProvider cannot be instantiated
[
https://issues.apache.org/jira/browse/DELTASPIKE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg updated DELTASPIKE-1458:
--
Fix Version/s: 2.0.0
(was: 1.9.7)
> DefaultConfigSourceProvider cannot be instantiated
> --
>
> Key: DELTASPIKE-1458
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1458
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
>Reporter: Michael Heydemann
>Priority: Major
> Fix For: 2.0.0
>
>
> Hello,
> I am trying to use the deltaspike test module (CdiTestRunner) in a Jakarta
> environment. Therefore for some of the dependencies I added the jakarta
> classifier. The test then fails with an exception. For demonstration purose I
> reduced the project to the necessary:
> I get this stack trace during test execution:
> {code:java}
> java.util.ServiceConfigurationError:
> org.apache.deltaspike.core.spi.config.ConfigSourceProvider: Provider
> org.apache.deltaspike.core.impl.config.DefaultConfigSourceProvider could not
> be instantiated
> at java.util.ServiceLoader.fail(ServiceLoader.java:232)
> at java.util.ServiceLoader.access$100(ServiceLoader.java:185)
> at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:384)
> at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
> at
> org.apache.deltaspike.core.util.ServiceUtils.loadServiceImplementations(ServiceUtils.java:81)
> at org.apache.deltaspike.core.impl.config.ConfigImpl.init(ConfigImpl.java:80)
> at
> org.apache.deltaspike.core.impl.config.ConfigProviderImpl.getConfig(ConfigProviderImpl.java:53)
> at
> org.apache.deltaspike.core.impl.config.ConfigProviderImpl.getConfig(ConfigProviderImpl.java:43)
> at
> org.apache.deltaspike.core.api.config.ConfigResolver.resolve(ConfigResolver.java:655)
> at
> org.apache.deltaspike.testcontrol.api.junit.TestBaseConfig$ContainerIntegration.(TestBaseConfig.java:29)
> at
> org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner.(CdiTestRunner.java:89)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> Caused by: java.lang.NoClassDefFoundError: jakarta/naming/NamingException
> at
> org.apache.deltaspike.core.impl.config.LocalJndiConfigSource.getPropertyValue(LocalJndiConfigSource.java:53)
> at
> org.apache.deltaspike.core.impl.config.BaseConfigSource.initOrdinal(BaseConfigSource.java:54)
> at
> org.apache.deltaspike.core.impl.config.LocalJndiConfigSource.(LocalJndiConfigSource.java:39)
> at
> org.apache.deltaspike.core.impl.config.DefaultConfigSourceProvider.(DefaultConfigSourceProvider.java:59)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:380)
> ... 26 more
> Caused by: java.lang.ClassNotFoundException: jakarta.naming.NamingException
> at java.net.URLClassLoader.findClass(URLClassLoader.java:387)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> ... 36 more{code}
>
> Here the pom.xml:
> {code:java}
>xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd;
> xmlns="http://maven.apache.org/POM/4.0.0;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;>
> 4.0.0
> org.example.cdi.test
> cdi-test
> 1.0.0-SNAPSHOT
> jar
>
> 1.9.6
>
>
>
> org.apache.deltaspike.modules
> deltaspike-test-control-module-api
> ${deltaspike.version}
> jakarta
> test
>
>
> org.apache.deltaspike.modules
> deltaspike-test-control-module-impl
> ${deltaspike.version}
> jakarta
> test
>
>
> org.apache.deltaspike.cdictrl
> deltaspike-cdictrl-weld
> ${deltaspike.version}
> jakarta
> test
>
>
> org.jboss.weld.se
> weld-se-core
> 4.0.0.Alpha3
> test
>
>
> junit
> junit
> 4.12
> test
>
>
>
> {code}
>
> And the empty test I would like to execute:
> {code:java}
> import org.apache.deltaspike.testcontrol.api.junit.CdiTestRunner;
> import org.junit.Test;
> import org.junit.runner.RunWith;
> @RunWith(CdiTestRunner.class)
> public class CdiTest {
> @Test
> public void test() {}
> }
> {code}
>
> I hope you can help me with this.
> Best Regrads,
> Michael
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DELTASPIKE-1456) Introduce default methods for some functions in ConfigSource
[
https://issues.apache.org/jira/browse/DELTASPIKE-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved DELTASPIKE-1456.
---
Resolution: Fixed
> Introduce default methods for some functions in ConfigSource
>
>
> Key: DELTASPIKE-1456
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1456
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Configuration
>Affects Versions: 1.9.6
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 1.9.7
>
>
> Right now our {{ConfigSource}} interface is still mostly an old Java6
> interface. We already use a default method for the onChange callback
> registration. We could also provide some other default methods, e.g. for
> {{getOrdinal()}} and {{isScannable().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1471) Remove @EnableInterceptors in favor of CDI InterceptionFactory
[ https://issues.apache.org/jira/browse/DELTASPIKE-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17821324#comment-17821324 ] ASF subversion and git services commented on DELTASPIKE-1471: - Commit 80a09955db24432b596345021c6997339d587958 in deltaspike's branch refs/heads/master from Thomas Andraschko [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=80a09955d ] DELTASPIKE-1471 Remove @EnableInterceptors in favor of CDI InterceptionFactory > Remove @EnableInterceptors in favor of CDI InterceptionFactory > -- > > Key: DELTASPIKE-1471 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1471 > Project: DeltaSpike > Issue Type: Task > Security Level: public(Regular issues) >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DELTASPIKE-1471) Remove @EnableInterceptors in favor of CDI InterceptionFactory
Thomas Andraschko created DELTASPIKE-1471: - Summary: Remove @EnableInterceptors in favor of CDI InterceptionFactory Key: DELTASPIKE-1471 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1471 Project: DeltaSpike Issue Type: Task Security Level: public (Regular issues) Reporter: Thomas Andraschko -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1471) Remove @EnableInterceptors in favor of CDI InterceptionFactory
[ https://issues.apache.org/jira/browse/DELTASPIKE-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-1471: -- Fix Version/s: 2.0 > Remove @EnableInterceptors in favor of CDI InterceptionFactory > -- > > Key: DELTASPIKE-1471 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1471 > Project: DeltaSpike > Issue Type: Task > Security Level: public(Regular issues) >Reporter: Thomas Andraschko >Priority: Major > Fix For: 2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DELTASPIKE-1471) Remove @EnableInterceptors in favor of CDI InterceptionFactory
[ https://issues.apache.org/jira/browse/DELTASPIKE-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-1471. --- Assignee: Thomas Andraschko Resolution: Fixed > Remove @EnableInterceptors in favor of CDI InterceptionFactory > -- > > Key: DELTASPIKE-1471 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1471 > Project: DeltaSpike > Issue Type: Task > Security Level: public(Regular issues) >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > Fix For: 2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DELTASPIKE-1469) WindowIdHtmlRenderer loads wrong Javascript file
[ https://issues.apache.org/jira/browse/DELTASPIKE-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-1469. --- Fix Version/s: 2.0 Resolution: Fixed > WindowIdHtmlRenderer loads wrong Javascript file > > > Key: DELTASPIKE-1469 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1469 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0 >Reporter: Peter Nimmervoll >Assignee: Thomas Andraschko >Priority: Major > Fix For: 2.0 > > > At least in the latest Mojarra release (4.0.5) the jsf.js was renamed to > faces.js but WindowIdHtmlRenderer still loads jsf.js. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (DELTASPIKE-1469) WindowIdHtmlRenderer loads wrong Javascript file
[ https://issues.apache.org/jira/browse/DELTASPIKE-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko reassigned DELTASPIKE-1469: - Assignee: Thomas Andraschko > WindowIdHtmlRenderer loads wrong Javascript file > > > Key: DELTASPIKE-1469 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1469 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0 >Reporter: Peter Nimmervoll >Assignee: Thomas Andraschko >Priority: Major > > At least in the latest Mojarra release (4.0.5) the jsf.js was renamed to > faces.js but WindowIdHtmlRenderer still loads jsf.js. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1469) WindowIdHtmlRenderer loads wrong Javascript file
[ https://issues.apache.org/jira/browse/DELTASPIKE-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807225#comment-17807225 ] ASF subversion and git services commented on DELTASPIKE-1469: - Commit 4530d147dcc6a895ff29a5b2d3401d341647411b in deltaspike's branch refs/heads/master from Thomas Andraschko [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=4530d147d ] DELTASPIKE-1469 > WindowIdHtmlRenderer loads wrong Javascript file > > > Key: DELTASPIKE-1469 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1469 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 2.0 >Reporter: Peter Nimmervoll >Assignee: Thomas Andraschko >Priority: Major > > At least in the latest Mojarra release (4.0.5) the jsf.js was renamed to > faces.js but WindowIdHtmlRenderer still loads jsf.js. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1470) PSQLException: ERROR: syntax error at or near ")" when using IN clause and empty list
[
https://issues.apache.org/jira/browse/DELTASPIKE-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807223#comment-17807223
]
Thomas Andraschko commented on DELTASPIKE-1470:
---
a PR would be very very great!
> PSQLException: ERROR: syntax error at or near ")" when using IN clause and
> empty list
> -
>
> Key: DELTASPIKE-1470
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1470
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Data-Module, JPA-Module
>Affects Versions: 1.9.4
>Reporter: Gilberto C Andrade
>Priority: Minor
>
> I'm getting this exception every time one query, that uses IN clause,
> receives an empty parameter:
> {code:java}
> //
> Caused by: javax.persistence.PersistenceException: Exception
> [EclipseLink-4002] (Eclipse Persistence Services -
> 2.7.7.v20200504-69f2c2b80d):
> org.eclipse.persistence.exceptions.DatabaseException
> Internal Exception: org.postgresql.util.PSQLException: ERROR: syntax error at
> or near ")"
> Posição: 396
> Error Code: 0
> Call: SELECT titulo_cobranca_id, ACEITE, codigo_movimento_remessa,
> codigo_movimento_retorno, documento, dt_documento, dt_efetivacao_credito,
> dt_emissao, dt_ocorrencia, dt_vencimento, especie, valor_juro,
> motivo_ocorrencia, valor_multa, nosso_numero, situacao, valor,
> valor_juros_multa_encargos, valor_pago, valor_tarifa, conta_bancaria_id,
> pagador_id FROM gace.titulo_cobranca WHERE (nosso_numero IN ())
> Query: ReadAllQuery(referenceClass=TituloCobranca sql="SELECT
> titulo_cobranca_id, ACEITE, codigo_movimento_remessa,
> codigo_movimento_retorno, documento, dt_documento, dt_efetivacao_credito,
> dt_emissao, dt_ocorrencia, dt_vencimento, especie, valor_juro,
> motivo_ocorrencia, valor_multa, nosso_numero, situacao, valor,
> valor_juros_multa_encargos, valor_pago, valor_tarifa, conta_bancaria_id,
> pagador_id FROM gace.titulo_cobranca WHERE (nosso_numero IN ?)")
> at
> org.eclipse.persistence.internal.jpa.QueryImpl.getDetailedException(QueryImpl.java:391)
> at
> org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:264)
> at
> org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:482)
> at org.apache.openejb.persistence.JtaQuery.getResultList(JtaQuery.java:87)
> at
> org.apache.deltaspike.data.impl.builder.result.QueryProcessorFactory$ListResultQueryProcessor.executeQuery(QueryProcessorFactory.java:96)
> at
> org.apache.deltaspike.data.impl.handler.CdiQueryInvocationContext.executeQuery(CdiQueryInvocationContext.java:253)
> at
> org.apache.deltaspike.data.impl.builder.AnnotatedQueryBuilder.execute(AnnotatedQueryBuilder.java:51)
> at
> org.apache.deltaspike.data.impl.builder.QueryBuilder.executeQuery(QueryBuilder.java:57)
> at
> org.apache.deltaspike.data.impl.builder.AnnotatedQueryBuilder$$OwbNormalScopeProxy0.executeQuery(org/apache/deltaspike/data/impl/builder/AnnotatedQueryBuilder.java)
> at
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeNonTransactional(TransactionalQueryRunner.java:62)
> at
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeQuery(TransactionalQueryRunner.java:57)
> at
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner$$OwbNormalScopeProxy0.executeQuery(org/apache/deltaspike/data/impl/tx/TransactionalQueryRunner.java)
> at
> org.apache.deltaspike.data.impl.handler.QueryHandler.process(QueryHandler.java:151)
> at
> org.apache.deltaspike.data.impl.handler.QueryHandler.invoke(QueryHandler.java:130)
> at
> org.apache.deltaspike.data.impl.handler.QueryHandler$$OwbNormalScopeProxy0.invoke(org/apache/deltaspike/data/impl/handler/QueryHandler.java)
> at
> org.apache.deltaspike.proxy.spi.invocation.DeltaSpikeProxyInvocationHandler.proceed(DeltaSpikeProxyInvocationHandler.java:97)
> at
> org.apache.deltaspike.proxy.spi.invocation.DeltaSpikeProxyInvocationHandler.invoke(DeltaSpikeProxyInvocationHandler.java:78)
> at
> org.apache.deltaspike.proxy.spi.invocation.DeltaSpikeProxyInvocationHandler$$OwbNormalScopeProxy0.invoke(org/apache/deltaspike/proxy/spi/invocation/DeltaSpikeProxyInvocationHandler.java)
> at
> br.gov.to.bem.gace.repository.TituloCobrancaRepository$$DSPartialBeanProxy.findAllByNossoNumero(Unknown
> Source)
> at
> br.gov.to.bem.gace.service.RetornoService.gerar(RetornoService.java:191)
> at
[jira] [Commented] (DELTASPIKE-1470) PSQLException: ERROR: syntax error at or near ")" when using IN clause and empty list
[
https://issues.apache.org/jira/browse/DELTASPIKE-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807201#comment-17807201
]
Gilberto C Andrade commented on DELTASPIKE-1470:
One discussion about it https://stackoverflow.com/q/3885/269514
> PSQLException: ERROR: syntax error at or near ")" when using IN clause and
> empty list
> -
>
> Key: DELTASPIKE-1470
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1470
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Data-Module, JPA-Module
>Affects Versions: 1.9.4
>Reporter: Gilberto C Andrade
>Priority: Minor
>
> I'm getting this exception every time one query, that uses IN clause,
> receives an empty parameter:
> {code:java}
> //
> Caused by: javax.persistence.PersistenceException: Exception
> [EclipseLink-4002] (Eclipse Persistence Services -
> 2.7.7.v20200504-69f2c2b80d):
> org.eclipse.persistence.exceptions.DatabaseException
> Internal Exception: org.postgresql.util.PSQLException: ERROR: syntax error at
> or near ")"
> Posição: 396
> Error Code: 0
> Call: SELECT titulo_cobranca_id, ACEITE, codigo_movimento_remessa,
> codigo_movimento_retorno, documento, dt_documento, dt_efetivacao_credito,
> dt_emissao, dt_ocorrencia, dt_vencimento, especie, valor_juro,
> motivo_ocorrencia, valor_multa, nosso_numero, situacao, valor,
> valor_juros_multa_encargos, valor_pago, valor_tarifa, conta_bancaria_id,
> pagador_id FROM gace.titulo_cobranca WHERE (nosso_numero IN ())
> Query: ReadAllQuery(referenceClass=TituloCobranca sql="SELECT
> titulo_cobranca_id, ACEITE, codigo_movimento_remessa,
> codigo_movimento_retorno, documento, dt_documento, dt_efetivacao_credito,
> dt_emissao, dt_ocorrencia, dt_vencimento, especie, valor_juro,
> motivo_ocorrencia, valor_multa, nosso_numero, situacao, valor,
> valor_juros_multa_encargos, valor_pago, valor_tarifa, conta_bancaria_id,
> pagador_id FROM gace.titulo_cobranca WHERE (nosso_numero IN ?)")
> at
> org.eclipse.persistence.internal.jpa.QueryImpl.getDetailedException(QueryImpl.java:391)
> at
> org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:264)
> at
> org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:482)
> at org.apache.openejb.persistence.JtaQuery.getResultList(JtaQuery.java:87)
> at
> org.apache.deltaspike.data.impl.builder.result.QueryProcessorFactory$ListResultQueryProcessor.executeQuery(QueryProcessorFactory.java:96)
> at
> org.apache.deltaspike.data.impl.handler.CdiQueryInvocationContext.executeQuery(CdiQueryInvocationContext.java:253)
> at
> org.apache.deltaspike.data.impl.builder.AnnotatedQueryBuilder.execute(AnnotatedQueryBuilder.java:51)
> at
> org.apache.deltaspike.data.impl.builder.QueryBuilder.executeQuery(QueryBuilder.java:57)
> at
> org.apache.deltaspike.data.impl.builder.AnnotatedQueryBuilder$$OwbNormalScopeProxy0.executeQuery(org/apache/deltaspike/data/impl/builder/AnnotatedQueryBuilder.java)
> at
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeNonTransactional(TransactionalQueryRunner.java:62)
> at
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeQuery(TransactionalQueryRunner.java:57)
> at
> org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner$$OwbNormalScopeProxy0.executeQuery(org/apache/deltaspike/data/impl/tx/TransactionalQueryRunner.java)
> at
> org.apache.deltaspike.data.impl.handler.QueryHandler.process(QueryHandler.java:151)
> at
> org.apache.deltaspike.data.impl.handler.QueryHandler.invoke(QueryHandler.java:130)
> at
> org.apache.deltaspike.data.impl.handler.QueryHandler$$OwbNormalScopeProxy0.invoke(org/apache/deltaspike/data/impl/handler/QueryHandler.java)
> at
> org.apache.deltaspike.proxy.spi.invocation.DeltaSpikeProxyInvocationHandler.proceed(DeltaSpikeProxyInvocationHandler.java:97)
> at
> org.apache.deltaspike.proxy.spi.invocation.DeltaSpikeProxyInvocationHandler.invoke(DeltaSpikeProxyInvocationHandler.java:78)
> at
> org.apache.deltaspike.proxy.spi.invocation.DeltaSpikeProxyInvocationHandler$$OwbNormalScopeProxy0.invoke(org/apache/deltaspike/proxy/spi/invocation/DeltaSpikeProxyInvocationHandler.java)
> at
> br.gov.to.bem.gace.repository.TituloCobrancaRepository$$DSPartialBeanProxy.findAllByNossoNumero(Unknown
> Source)
> at
> br.gov.to.bem.gace.service.
[jira] [Created] (DELTASPIKE-1470) PSQLException: ERROR: syntax error at or near ")" when using IN clause and empty list
Gilberto C Andrade created DELTASPIKE-1470:
--
Summary: PSQLException: ERROR: syntax error at or near ")" when
using IN clause and empty list
Key: DELTASPIKE-1470
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1470
Project: DeltaSpike
Issue Type: Improvement
Security Level: public (Regular issues)
Components: Data-Module, JPA-Module
Affects Versions: 1.9.4
Reporter: Gilberto C Andrade
I'm getting this exception every time one query, that uses IN clause, receives
an empty parameter:
{code:java}
//
Caused by: javax.persistence.PersistenceException: Exception [EclipseLink-4002]
(Eclipse Persistence Services - 2.7.7.v20200504-69f2c2b80d):
org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: org.postgresql.util.PSQLException: ERROR: syntax error at
or near ")"
Posição: 396
Error Code: 0
Call: SELECT titulo_cobranca_id, ACEITE, codigo_movimento_remessa,
codigo_movimento_retorno, documento, dt_documento, dt_efetivacao_credito,
dt_emissao, dt_ocorrencia, dt_vencimento, especie, valor_juro,
motivo_ocorrencia, valor_multa, nosso_numero, situacao, valor,
valor_juros_multa_encargos, valor_pago, valor_tarifa, conta_bancaria_id,
pagador_id FROM gace.titulo_cobranca WHERE (nosso_numero IN ())
Query: ReadAllQuery(referenceClass=TituloCobranca sql="SELECT
titulo_cobranca_id, ACEITE, codigo_movimento_remessa, codigo_movimento_retorno,
documento, dt_documento, dt_efetivacao_credito, dt_emissao, dt_ocorrencia,
dt_vencimento, especie, valor_juro, motivo_ocorrencia, valor_multa,
nosso_numero, situacao, valor, valor_juros_multa_encargos, valor_pago,
valor_tarifa, conta_bancaria_id, pagador_id FROM gace.titulo_cobranca WHERE
(nosso_numero IN ?)")
at
org.eclipse.persistence.internal.jpa.QueryImpl.getDetailedException(QueryImpl.java:391)
at
org.eclipse.persistence.internal.jpa.QueryImpl.executeReadQuery(QueryImpl.java:264)
at
org.eclipse.persistence.internal.jpa.QueryImpl.getResultList(QueryImpl.java:482)
at org.apache.openejb.persistence.JtaQuery.getResultList(JtaQuery.java:87)
at
org.apache.deltaspike.data.impl.builder.result.QueryProcessorFactory$ListResultQueryProcessor.executeQuery(QueryProcessorFactory.java:96)
at
org.apache.deltaspike.data.impl.handler.CdiQueryInvocationContext.executeQuery(CdiQueryInvocationContext.java:253)
at
org.apache.deltaspike.data.impl.builder.AnnotatedQueryBuilder.execute(AnnotatedQueryBuilder.java:51)
at
org.apache.deltaspike.data.impl.builder.QueryBuilder.executeQuery(QueryBuilder.java:57)
at
org.apache.deltaspike.data.impl.builder.AnnotatedQueryBuilder$$OwbNormalScopeProxy0.executeQuery(org/apache/deltaspike/data/impl/builder/AnnotatedQueryBuilder.java)
at
org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeNonTransactional(TransactionalQueryRunner.java:62)
at
org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeQuery(TransactionalQueryRunner.java:57)
at
org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner$$OwbNormalScopeProxy0.executeQuery(org/apache/deltaspike/data/impl/tx/TransactionalQueryRunner.java)
at
org.apache.deltaspike.data.impl.handler.QueryHandler.process(QueryHandler.java:151)
at
org.apache.deltaspike.data.impl.handler.QueryHandler.invoke(QueryHandler.java:130)
at
org.apache.deltaspike.data.impl.handler.QueryHandler$$OwbNormalScopeProxy0.invoke(org/apache/deltaspike/data/impl/handler/QueryHandler.java)
at
org.apache.deltaspike.proxy.spi.invocation.DeltaSpikeProxyInvocationHandler.proceed(DeltaSpikeProxyInvocationHandler.java:97)
at
org.apache.deltaspike.proxy.spi.invocation.DeltaSpikeProxyInvocationHandler.invoke(DeltaSpikeProxyInvocationHandler.java:78)
at
org.apache.deltaspike.proxy.spi.invocation.DeltaSpikeProxyInvocationHandler$$OwbNormalScopeProxy0.invoke(org/apache/deltaspike/proxy/spi/invocation/DeltaSpikeProxyInvocationHandler.java)
at
br.gov.to.bem.gace.repository.TituloCobrancaRepository$$DSPartialBeanProxy.findAllByNossoNumero(Unknown
Source)
at br.gov.to.bem.gace.service.RetornoService.gerar(RetornoService.java:191)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext$Invocation.invoke(ReflectionInvocationContext.java:205)
at
org.apache.openejb.core.interceptor.ReflectionInvocationContext.proceed(ReflectionInvocationContext.java:186)
at
org.apache.openejb.monitoring.StatsInterceptor.re
[jira] [Created] (DELTASPIKE-1469) WindowIdHtmlRenderer loads wrong Javascript file
Peter Nimmervoll created DELTASPIKE-1469: Summary: WindowIdHtmlRenderer loads wrong Javascript file Key: DELTASPIKE-1469 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1469 Project: DeltaSpike Issue Type: Bug Security Level: public (Regular issues) Affects Versions: 2.0 Reporter: Peter Nimmervoll At least in the latest Mojarra release (4.0.5) the jsf.js was renamed to faces.js but WindowIdHtmlRenderer still loads jsf.js. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DELTASPIKE-1468) AuditProvider (PrincipalProvider/TimestampsProvider) not working
[ https://issues.apache.org/jira/browse/DELTASPIKE-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-1468. --- Resolution: Fixed > AuditProvider (PrincipalProvider/TimestampsProvider) not working > > > Key: DELTASPIKE-1468 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1468 > Project: DeltaSpike > Issue Type: New Feature > Security Level: public(Regular issues) > Components: JPA-Module >Affects Versions: 2.0 > Environment: symptom exhibited on Payara6 WELD >Reporter: Phillip Ross >Priority: Blocker > > PrincipalProvider and TimestampsProvider stop working in v2.0 (probably since > DELTASPIKE-1466) as they lack an explicit CDI scope annotation. Since they > are loaded/referenced programmatically, no error is thrown by the bean > container explicitly, but rather they are just never resolved and effectively > ignored. > A simple fix is to add @Dependent CDI scope annotation (probably an oversight > from the CDI-3 refactor). > I'll open a GitHub PR with this fix next. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1468) AuditProvider (PrincipalProvider/TimestampsProvider) not working
[ https://issues.apache.org/jira/browse/DELTASPIKE-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-1468: -- Fix Version/s: 2.0 > AuditProvider (PrincipalProvider/TimestampsProvider) not working > > > Key: DELTASPIKE-1468 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1468 > Project: DeltaSpike > Issue Type: New Feature > Security Level: public(Regular issues) > Components: JPA-Module >Affects Versions: 2.0 > Environment: symptom exhibited on Payara6 WELD >Reporter: Phillip Ross >Priority: Blocker > Fix For: 2.0 > > > PrincipalProvider and TimestampsProvider stop working in v2.0 (probably since > DELTASPIKE-1466) as they lack an explicit CDI scope annotation. Since they > are loaded/referenced programmatically, no error is thrown by the bean > container explicitly, but rather they are just never resolved and effectively > ignored. > A simple fix is to add @Dependent CDI scope annotation (probably an oversight > from the CDI-3 refactor). > I'll open a GitHub PR with this fix next. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1468) AuditProvider (PrincipalProvider/TimestampsProvider) not working
[ https://issues.apache.org/jira/browse/DELTASPIKE-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17805344#comment-17805344 ] ASF subversion and git services commented on DELTASPIKE-1468: - Commit e7357d14309b30e019ee46e6a73d507d04138b1e in deltaspike's branch refs/heads/master from Thomas Andraschko [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=e7357d143 ] Merge pull request #138 from phillipross/topic/fix/DELTASPIKE-1468 add explicit dependent scope to PrincipalProvider and TimestampsProvider beans > AuditProvider (PrincipalProvider/TimestampsProvider) not working > > > Key: DELTASPIKE-1468 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1468 > Project: DeltaSpike > Issue Type: New Feature > Security Level: public(Regular issues) > Components: JPA-Module >Affects Versions: 2.0 > Environment: symptom exhibited on Payara6 WELD >Reporter: Phillip Ross >Priority: Blocker > > PrincipalProvider and TimestampsProvider stop working in v2.0 (probably since > DELTASPIKE-1466) as they lack an explicit CDI scope annotation. Since they > are loaded/referenced programmatically, no error is thrown by the bean > container explicitly, but rather they are just never resolved and effectively > ignored. > A simple fix is to add @Dependent CDI scope annotation (probably an oversight > from the CDI-3 refactor). > I'll open a GitHub PR with this fix next. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (DELTASPIKE-1468) AuditProvider (PrincipalProvider/TimestampsProvider) not working
Phillip Ross created DELTASPIKE-1468: Summary: AuditProvider (PrincipalProvider/TimestampsProvider) not working Key: DELTASPIKE-1468 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1468 Project: DeltaSpike Issue Type: New Feature Security Level: public (Regular issues) Components: JPA-Module Affects Versions: 2.0 Environment: symptom exhibited on Payara6 WELD Reporter: Phillip Ross PrincipalProvider and TimestampsProvider stop working in v2.0 (probably since DELTASPIKE-1466) as they lack an explicit CDI scope annotation. Since they are loaded/referenced programmatically, no error is thrown by the bean container explicitly, but rather they are just never resolved and effectively ignored. A simple fix is to add @Dependent CDI scope annotation (probably an oversight from the CDI-3 refactor). I'll open a GitHub PR with this fix next. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1467) Saving existing entity throws an exception
[
https://issues.apache.org/jira/browse/DELTASPIKE-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko updated DELTASPIKE-1467:
--
Fix Version/s: 2.0
> Saving existing entity throws an exception
> --
>
> Key: DELTASPIKE-1467
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1467
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Data-Module
>Affects Versions: 1.9.6
>Reporter: Stonewoodman
>Priority: Major
> Fix For: 2.0
>
>
> {code:java}
> @Entity(name = "Foo")
> @Table(name = "foo")
> public class FooEntity implements Serializable
> {
> @Id
> @GeneratedValue(strategy = GenerationType.IDENTITY)
> private Long id;
> ...
> }{code}
> {code:java}
> @Transactional
> @Repository(forEntity = FooEntity.class)
> public abstract class FooRepository extends
> AbstractEntityRepository
> {
> ...
> }
> {code}
> Loading an entity in JSF
> Edit and save it.
> It generates following exception
> Caused by: javax.transaction.RollbackException: Transaction is marked for
> rollback
> The origin error occurs in CdiQueryInvocationContext.java#countCheck(Object,
> Property)
> Because for this generated select is using the class name instead of entity
> name.
> See PR
> https://github.com/apache/deltaspike/pull/137
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DELTASPIKE-1467) Saving existing entity throws an exception
[
https://issues.apache.org/jira/browse/DELTASPIKE-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved DELTASPIKE-1467.
---
Resolution: Fixed
> Saving existing entity throws an exception
> --
>
> Key: DELTASPIKE-1467
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1467
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Data-Module
>Affects Versions: 1.9.6
>Reporter: Stonewoodman
>Priority: Major
> Fix For: 2.0
>
>
> {code:java}
> @Entity(name = "Foo")
> @Table(name = "foo")
> public class FooEntity implements Serializable
> {
> @Id
> @GeneratedValue(strategy = GenerationType.IDENTITY)
> private Long id;
> ...
> }{code}
> {code:java}
> @Transactional
> @Repository(forEntity = FooEntity.class)
> public abstract class FooRepository extends
> AbstractEntityRepository
> {
> ...
> }
> {code}
> Loading an entity in JSF
> Edit and save it.
> It generates following exception
> Caused by: javax.transaction.RollbackException: Transaction is marked for
> rollback
> The origin error occurs in CdiQueryInvocationContext.java#countCheck(Object,
> Property)
> Because for this generated select is using the class name instead of entity
> name.
> See PR
> https://github.com/apache/deltaspike/pull/137
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DELTASPIKE-1467) Saving existing entity throws an exception
Stonewoodman created DELTASPIKE-1467:
Summary: Saving existing entity throws an exception
Key: DELTASPIKE-1467
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1467
Project: DeltaSpike
Issue Type: Bug
Security Level: public (Regular issues)
Components: Data-Module
Affects Versions: 1.9.6
Reporter: Stonewoodman
{code:java}
@Entity(name = "Foo")
@Table(name = "foo")
public class FooEntity implements Serializable
{
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
...
}{code}
{code:java}
@Transactional
@Repository(forEntity = FooEntity.class)
public abstract class FooRepository extends AbstractEntityRepository
{
...
}
{code}
Loading an entity in JSF
Edit and save it.
It generates following exception
Caused by: javax.transaction.RollbackException: Transaction is marked for
rollback
The origin error occurs in CdiQueryInvocationContext.java#countCheck(Object,
Property)
Because for this generated select is using the class name instead of entity
name.
See PR
https://github.com/apache/deltaspike/pull/137
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1437) DeltaSpike-2.0 umbrella ticket
[ https://issues.apache.org/jira/browse/DELTASPIKE-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787949#comment-17787949 ] ASF subversion and git services commented on DELTASPIKE-1437: - Commit fd13102bca5aade74f08fe41af2cb6d3663d6fe0 in deltaspike's branch refs/heads/master from Mark Struberg [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=fd13102bc ] DELTASPIKE-1437 temporarily disable last broken test > DeltaSpike-2.0 umbrella ticket > -- > > Key: DELTASPIKE-1437 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1437 > Project: DeltaSpike > Issue Type: Task > Security Level: public(Regular issues) >Reporter: Mark Struberg >Priority: Major > Fix For: 2.0 > > > This is an umbrella ticket for various DeltaSpike 2.0 tasks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DELTASPIKE-1466) move beans.xml to CDI-3.0 style
[
https://issues.apache.org/jira/browse/DELTASPIKE-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved DELTASPIKE-1466.
---
Resolution: Fixed
> move beans.xml to CDI-3.0 style
> ---
>
> Key: DELTASPIKE-1466
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1466
> Project: DeltaSpike
> Issue Type: Sub-task
> Security Level: public(Regular issues)
> Components: Core
>Affects Versions: 2.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0
>
>
> Since we now target EE9 at least we also have to update our beans.xml.
> This has mainly to do with CDI-4.0 in JakartaEE10 re-defined the behaviour of
> empty beans.xml files from bean-discovery-mode "all" to "annotated", breaking
> tons of existing code.
> To prevent any behaviour changes for DeltaSpike users we now explicitly
> define a {{bean-discovery-mode}} ourselfs. And we also leverage the
> {{}} modus of CDI-2.0.
> bean-discovery-mode "all" + has the effect that all classes which are
> CDI candidates get scanned and a {{ProcessAnnotatedType}} event gets fired.
> But with the mode we ONLY create beans for AnnotatedTypes which are
> explicitly defined. This is a good compromise between being able to scan all
> classes via CDI Extensions but still not getting any superfluous CDI beans as
> automatically {{@Dependent}} scoped beans
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1466) move beans.xml to CDI-3.0 style
[
https://issues.apache.org/jira/browse/DELTASPIKE-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17785288#comment-17785288
]
ASF subversion and git services commented on DELTASPIKE-1466:
-
Commit 3be1a101249805caa81ffa15abc360b6d8030db0 in deltaspike's branch
refs/heads/master from Mark Struberg
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=3be1a1012 ]
DELTASPIKE-1466 move to CDI-3.0 style beans.xml
Also explicitly define a bean-discovery-mode to prevent backward compat issues
with non backward compatible CDI-4.0 spec changes.
> move beans.xml to CDI-3.0 style
> ---
>
> Key: DELTASPIKE-1466
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1466
> Project: DeltaSpike
> Issue Type: Sub-task
> Security Level: public(Regular issues)
> Components: Core
>Affects Versions: 2.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0
>
>
> Since we now target EE9 at least we also have to update our beans.xml.
> This has mainly to do with CDI-4.0 in JakartaEE10 re-defined the behaviour of
> empty beans.xml files from bean-discovery-mode "all" to "annotated", breaking
> tons of existing code.
> To prevent any behaviour changes for DeltaSpike users we now explicitly
> define a {{bean-discovery-mode}} ourselfs. And we also leverage the
> {{}} modus of CDI-2.0.
> bean-discovery-mode "all" + has the effect that all classes which are
> CDI candidates get scanned and a {{ProcessAnnotatedType}} event gets fired.
> But with the mode we ONLY create beans for AnnotatedTypes which are
> explicitly defined. This is a good compromise between being able to scan all
> classes via CDI Extensions but still not getting any superfluous CDI beans as
> automatically {{@Dependent}} scoped beans
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DELTASPIKE-1466) move beans.xml to CDI-3.0 style
Mark Struberg created DELTASPIKE-1466:
-
Summary: move beans.xml to CDI-3.0 style
Key: DELTASPIKE-1466
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1466
Project: DeltaSpike
Issue Type: Sub-task
Security Level: public (Regular issues)
Components: Core
Affects Versions: 2.0
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 2.0
Since we now target EE9 at least we also have to update our beans.xml.
This has mainly to do with CDI-4.0 in JakartaEE10 re-defined the behaviour of
empty beans.xml files from bean-discovery-mode "all" to "annotated", breaking
tons of existing code.
To prevent any behaviour changes for DeltaSpike users we now explicitly define
a {{bean-discovery-mode}} ourselfs. And we also leverage the {{}} modus
of CDI-2.0.
bean-discovery-mode "all" + has the effect that all classes which are
CDI candidates get scanned and a {{ProcessAnnotatedType}} event gets fired. But
with the mode we ONLY create beans for AnnotatedTypes which are
explicitly defined. This is a good compromise between being able to scan all
classes via CDI Extensions but still not getting any superfluous CDI beans as
automatically {{@Dependent}} scoped beans
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (DELTASPIKE-740) Data module causes arquillian-weld-ee-embedded to fail when persistence.xml is present
[
https://issues.apache.org/jira/browse/DELTASPIKE-740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko closed DELTASPIKE-740.
Resolution: Incomplete
no feedback since years
> Data module causes arquillian-weld-ee-embedded to fail when persistence.xml
> is present
> --
>
> Key: DELTASPIKE-740
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-740
> Project: DeltaSpike
> Issue Type: Bug
> Components: Data-Module
>Affects Versions: 1.0.3
> Environment: arquillian:1.0.3.Final
> org.jboss.arquillian.container:arquillian-weld-ee-embedded-1.1:1.0.0.CR8
>Reporter: Ove Ranheim
>Assignee: Thomas Hug
>Priority: Major
>
> When persistence.xml is added to shrinkwrap using weld-ee container the Data
> module fails to load and the test case crashes.
> {code}
> @Deployment
> public static WebArchive createDeployment() {
> return ShrinkWrap.create(WebArchive.class, "test.war")
> .addAsLibraries(ShrinkWrapArchiveUtil.getArchives(null,
> "META-INF/beans.xml", new String[]{
> "org.apache.deltaspike.core",
> "org.apache.deltaspike.descriptor.category"
> }, null, null))
> .addPackage(MyRepository.class.getPackage())
> .addClass(TestEntity.class)
> .addAsResource("META-INF/persistence.xml")
> .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml")
> ;
> }
> {code}
> {code}
> INFO: class: org.apache.deltaspike.data.impl.RepositoryExtension
> activated=true
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: -123,542.439
> sec <<< FAILURE! - in org.jboss.weld.WeldTransactionServicesTest
> org.jboss.weld.WeldTransactionServicesTest Time elapsed: -123,542.44 sec
> <<< ERROR!
> org.jboss.weld.exceptions.DefinitionException: Exception List with 1
> exceptions:
> Exception 0 :
> java.lang.IllegalArgumentException: URL does not exist:
> archive:test.war/WEB-INF/classes/META-INF/persistence.xml
> at
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readFromUrl(DescriptorReader.java:64)
> at
> org.apache.deltaspike.data.impl.meta.unit.DescriptorReader.readAllFromClassPath(DescriptorReader.java:50)
> at
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnitReader.readAll(PersistenceUnitReader.java:37)
> at
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.readPersistenceXmls(PersistenceUnits.java:98)
> at
> org.apache.deltaspike.data.impl.meta.unit.PersistenceUnits.init(PersistenceUnits.java:45)
> at
> org.apache.deltaspike.data.impl.RepositoryExtension.beforeBeanDiscovery(RepositoryExtension.java:74)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at
> org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:90)
> at
> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:271)
> at
> org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
> at
> org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:258)
> at
> org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:237)
> at
> org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:174)
> at
> org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:133)
> at
> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:107)
> at
> org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54)
> at
> org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42)
> at
> org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:45)
> at
> org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:385)
> at
> org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
> at
> org.jboss.arq
[jira] [Closed] (DELTASPIKE-1450) Facing issue after Seam3 to deltaspike migration
[ https://issues.apache.org/jira/browse/DELTASPIKE-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko closed DELTASPIKE-1450. - Resolution: Incomplete i will close this for now if you can post a reproducer, we can have a look > Facing issue after Seam3 to deltaspike migration > > > Key: DELTASPIKE-1450 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1450 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.9.5 > Environment: dev >Reporter: Narayan Datt Rai >Priority: Major > Attachments: seam3ToDeltaspikeMigrationError.log > > > Hi Team, > > We have recently migrated sema3 to deltaspike. > > Soler, JSF, CDI Weld were used in while seam3 was there. Now with deltaspike, > we are not able to trigger the java code from index.xhtml, which was working > before deltraspike. > > Below is the error seen while accessing the xhtml page. > > > Error Rendering View[/login.xhtml] > [exec] 44030: FND-Bhanu: Mar 25 2022 06:29:28.527 +: > %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default > task-14][part=44029.2/78]: javax.el.ELException: /login.xhtml: The class > 'com.cisco.cgms.webapp.aaa.CgmsUser' does not have the property > 'restoreMessages'. > [exec] 44031: FND-Bhanu: Mar 25 2022 06:29:28.527 +: > %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default > task-14][part=44029.3/78]: at > com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:47) > [exec] 44032: FND-Bhanu: Mar 25 2022 06:29:28.527 +: > %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default > task-14][part=44029.4/78]: at > com.sun.faces.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:41) > [exec] 44033: FND-Bhanu: Mar 25 2022 06:29:28.527 +: > %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default > task-14][part=44029.5/78]: at > com.sun.faces.facelets.compiler.UILeaf.encodeAll(UILeaf.java:169) > [exec] 44034: FND-Bhanu: Mar 25 2022 06:29:28.527 +: > %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default > task-14][part=44029.6/78]: at > javax.faces.component.UIComponent.encodeAll(UIComponent.java:1650) > [exec] 44035: FND-Bhanu: Mar 25 2022 06:29:28.527 +: > %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default > task-14][part=44029.7/78]: at > com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:468) > [exec] 44036: FND-Bhanu: Mar 25 2022 06:29:28.527 +: > %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default > task-14][part=44029.8/78]: at > com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:170) > [exec] 44037: FND-Bhanu: Mar 25 2022 06:29:28.527 +: > %IOTFND-3-UNSPECIFIED: %[ch=application][sev=ERROR][tid=default > task-14][part=44029.9/78]: at > javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:132) > > > Log file is attached for further analysis. > > Please help us to resolve this issue. > > Thanks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DELTASPIKE-1461) Cleanup Window/ViewAcessScoped
[ https://issues.apache.org/jira/browse/DELTASPIKE-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko closed DELTASPIKE-1461. - Resolution: Fixed i will close this for now i didnt remove WindowContext/Scoped for now > Cleanup Window/ViewAcessScoped > -- > > Key: DELTASPIKE-1461 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1461 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: Thomas Andraschko >Priority: Major > Fix For: 2.0 > > > Currently ViewAcessScoped and WindowScoped is in DS Core > since Faces 4.0, we could just remove WindowScoped and change all occurances > to Faces ClientWindowScoped > this would require to move ViewAcessScoped to the faces module > IMO we should do this for a cleanup, i dont think ANYONE will ever use > ViewAcessScoped outside of Faces. > WDYT [~struberg] [~gpetracek]? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-1434. --- Resolution: Fixed basically done > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Fix For: 2.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko updated DELTASPIKE-1434: -- Fix Version/s: 2.0 > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Fix For: 2.0 > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DELTASPIKE-1381) Method Expressions not validated at deployment time
[ https://issues.apache.org/jira/browse/DELTASPIKE-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko closed DELTASPIKE-1381. - Resolution: Incomplete > Method Expressions not validated at deployment time > --- > > Key: DELTASPIKE-1381 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1381 > Project: DeltaSpike > Issue Type: Bug > Components: Data-Module >Affects Versions: 1.9.0 > Environment: JDK 8 > Postgres 10 > Hibernate 5.3.6 > WildFly 13.0.0 >Reporter: Ehsan Zaery Moghaddam >Priority: Minor > > In the documentation it's explicitly mentioned that method expressions are > validated upon deployment to see if there is any typo in them: > *_Note that DeltaSpike will validate those expressions during startup, so you > will notice early in case you have a typo in those expressions_*. > > But seems this validation doesn't happen during deployment and the code fails > when the given method is being called. In the following example, the > "LessThan" comparator is misspelled and the stack trace of the runtime error > is as below: > > *Caused by: org.apache.deltaspike.data.api.QueryInvocationException: Failed > calling Repository: > [Repository=com.one.paymentgateway.persistence.repository.PendingCaptureRepository,entity=com.one.paymentgateway.persistence.entity.PendingCaptureEntity,method=findAnyByPendingTimeLesThanEqualsOrderByPendingTime,* > at > org.apache.deltaspike.data.impl.builder.DelegateQueryBuilder.execute(DelegateQueryBuilder.java:83) > at > org.apache.deltaspike.data.impl.builder.QueryBuilder.executeQuery(QueryBuilder.java:57) > at > org.apache.deltaspike.data.impl.builder.DelegateQueryBuilder$Proxy$_$$_WeldClientProxy.executeQuery(Unknown > Source) > at > org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeNonTransactional(TransactionalQueryRunner.java:62) > at > org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner.executeQuery(TransactionalQueryRunner.java:57) > at > org.apache.deltaspike.data.impl.tx.TransactionalQueryRunner$Proxy$_$$_WeldClientProxy.executeQuery(Unknown > Source) > at > org.apache.deltaspike.data.impl.handler.QueryHandler.process(QueryHandler.java:151) > ... 161 more -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17765831#comment-17765831 ] Thomas Frühbeck commented on DELTASPIKE-1434: - I really care about OSS and would like to continue using deltaspike! I tried a spike to continue the existing work on migration to jakarta namespace and it works for me on Wildfly 29.0.1.Final. Unfortunately I have neither experience nor use for other containers. As I see the variants of EE and CDI containers is enormous and mostly outdated. Additionally file like the META-INF/services definitions would have to be renamed. Wouldnt it make sense to remove old CDI support? Anycase I would try to assist in lifting Deltaspike to jakarta if needed. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[
https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17722247#comment-17722247
]
Krzysztof Wolny commented on DELTASPIKE-1434:
-
FYI: We migrated from DeltaSpike and replaced it with Weld (already been there
partially). We also dropped the usage of {{{}CDIUnit{}}}, which also is not
migrated jet, and replaced it with {{{}weld-testing{}}}.
> Namespace change javax to jakarta
> -
>
> Key: DELTASPIKE-1434
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Core
>Affects Versions: 1.9.5
>Reporter: John Smith
>Assignee: Mark Struberg
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Is there a plan to make the namespace change from javax to jakartaee. Seems
> to be required to use deltaspike in the future.
> https://jakarta.ee/compatibility/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1437) DeltaSpike-2.0 umbrella ticket
[ https://issues.apache.org/jira/browse/DELTASPIKE-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721277#comment-17721277 ] ASF subversion and git services commented on DELTASPIKE-1437: - Commit 2e575abc3faae68cb1a266923254c2cc80661592 in deltaspike's branch refs/heads/master from Mark Struberg [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=2e575abc3 ] DELTASPIKE-1437 min java version is now 11 > DeltaSpike-2.0 umbrella ticket > -- > > Key: DELTASPIKE-1437 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1437 > Project: DeltaSpike > Issue Type: Task > Security Level: public(Regular issues) >Reporter: Mark Struberg >Priority: Major > Fix For: 2.0 > > > This is an umbrella ticket for various DeltaSpike 2.0 tasks -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1465) print ConfigSource of the values for deltaspike.config.log
[
https://issues.apache.org/jira/browse/DELTASPIKE-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721276#comment-17721276
]
ASF subversion and git services commented on DELTASPIKE-1465:
-
Commit 5fcbc344919e74baf14dad92e931a96b3dd3bd4f in deltaspike's branch
refs/heads/master from Mark Struberg
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=5fcbc3449 ]
DELTASPIKE-1465 print effective ConfigSource per value
> print ConfigSource of the values for deltaspike.config.log
> --
>
> Key: DELTASPIKE-1465
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1465
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Configuration
>Affects Versions: 2.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0
>
>
> When using the configuration {code}deltaspike.config.log=true{code}
> DeltaSpike prints the resolved configuraiton at startup. Right now this
> contains the list of ConfigSources and all configured keys plus their values.
> This could be further enhanced by also printing the ConfigSource from which
> the value finally got picked up.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DELTASPIKE-1465) print ConfigSource of the values for deltaspike.config.log
[
https://issues.apache.org/jira/browse/DELTASPIKE-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Struberg resolved DELTASPIKE-1465.
---
Resolution: Fixed
> print ConfigSource of the values for deltaspike.config.log
> --
>
> Key: DELTASPIKE-1465
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1465
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Configuration
>Affects Versions: 2.0
>Reporter: Mark Struberg
>Assignee: Mark Struberg
>Priority: Major
> Fix For: 2.0
>
>
> When using the configuration {code}deltaspike.config.log=true{code}
> DeltaSpike prints the resolved configuraiton at startup. Right now this
> contains the list of ConfigSources and all configured keys plus their values.
> This could be further enhanced by also printing the ConfigSource from which
> the value finally got picked up.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DELTASPIKE-1465) print ConfigSource of the values for deltaspike.config.log
Mark Struberg created DELTASPIKE-1465:
-
Summary: print ConfigSource of the values for deltaspike.config.log
Key: DELTASPIKE-1465
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1465
Project: DeltaSpike
Issue Type: Improvement
Security Level: public (Regular issues)
Components: Configuration
Affects Versions: 2.0
Reporter: Mark Struberg
Assignee: Mark Struberg
Fix For: 2.0
When using the configuration {code}deltaspike.config.log=true{code} DeltaSpike
prints the resolved configuraiton at startup. Right now this contains the list
of ConfigSources and all configured keys plus their values.
This could be further enhanced by also printing the ConfigSource from which the
value finally got picked up.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715964#comment-17715964 ] Romain Manni-Bucau commented on DELTASPIKE-1434: [~vanta] EE always had been selected for its stability until they start breaking and the adoption decrease so yes they exist and try to migrate without having to do it every year cause it costs money. To answer your timeline question: it is not about the timeline since ASF does not have any strong timeline, it is likely more about the investment you can do. For example join the discussion about the pruning on the list and when there is an agreement, if you cover all mainstream servers (I guess payara, tomee, wildfly) for the IT then the release is 3 days (vote process) but has no real blocker nor challenge. If you consider the project as a consommable and don't care about the OSS side I'm tempted to say you should migrate to something more commercial like quarkus (money helps to maintain software in real life ;)). > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715959#comment-17715959 ] Krzysztof Wolny commented on DELTASPIKE-1434: - > Not for end users when they need to change their code every year/month (maybe > you are an exception), the EE and Microprofile mess prove it being very true > for a lot of our user base. If the EE world is changing, its users have to adopt or leave if it's too fast for them. It's not DS fault that these changes happen, no one will blame you. People will blame if these changes are not adopted in DS. Why do we (waiting users) have to wait for these slower ones maybe they don't even exist...? Anyway, do we have a timeline for this change or a timeline for a timeline for this change? All we need is clarity: should we wait or migrate to other solutions. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715794#comment-17715794 ] Romain Manni-Bucau commented on DELTASPIKE-1434: > Releases are cheap! There is no rule saying that a project can't make several > major releases in a (short) period. Not for end users when they need to change their code every year/month (maybe you are an exception), the EE and Microprofile mess prove it being very true for a lot of our user base. > And then take your time to make any improvements on top for the next major > release. Deleting will not happen *on top*, this is the main issue and why there is a discussion. > IMO it would be better to make a release that just replaces "javax" with > "jakarta" of the current/latest javax version of a lib. There is no need of a > major version here. One could use even a Maven classifier. I was for the classifier option to have an early access flavor but the breaking change in EE API limit this solution now and will not enable to run in any jakarta server so we have to do the big jump sadly and therefore the IT question which require some investment. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715791#comment-17715791 ] Jeremy Landis commented on DELTASPIKE-1434: --- Classifier was there but deltaspike broke it. 1.9.7 release would have resolved that but now it's much more... Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg> > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715790#comment-17715790 ] Martin Tzvetanov Grigorov commented on DELTASPIKE-1434: --- By the way, I also got rid of DeltaSpike, so I am no more interested in the Jakarta change. I will unsubscribe myself from this ticket. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715784#comment-17715784 ] Martin Tzvetanov Grigorov commented on DELTASPIKE-1434: --- "this is a breaking version so you have to ask yourself as a project maintainer what you want to break more to give some stability to users" Releases are cheap! There is no rule saying that a project can't make several major releases in a (short) period. IMO it would be better to make a release that just replaces "javax" with "jakarta" of the current/latest javax version of a lib. There is no need of a major version here. One could use even a Maven classifier. And then take your time to make any improvements on top for the next major release. What we have now is 2 years of waiting... And probably more ahead ... > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715768#comment-17715768 ] Romain Manni-Bucau commented on DELTASPIKE-1434: [~mgrigorov] this can look accurate but in pactise you hide the most important points: * this is a breaking version so you have to ask yourself as a project maintainer what you want to break more to give some stability to users (if you don't it means you will do a pure conversion release then break with next major, likely worse), * javax -> jakarta is not only about renaming, EE broke itself just after the renaming (CDI API for ex) so this is not only a renaming thing to migrate, this is also why the bytecode manipulation often works but also fails regularly, * even following this rule you still hit the fact containers are not up to date or no more compatible so you still have IT work > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715729#comment-17715729 ] Martin Tzvetanov Grigorov commented on DELTASPIKE-1434: --- "there are discussions on what should be kept for v2 (jakarta) or not on the list." This is the main problem for all Javax/Jakarta projects - they all try to add/remove something in addition to the simple renaming of the packages/imports. And this makes this simple task so problematic. I see the same problem in commons-fileupload, in RestEasy, in cdi-unit and few more projects. Most of us (the users) just want the same old javax-based library but updated to jakarta. Some projects update the sources, others use bytecode manipulation to accomplish the task. Both are fine for us (the users)! What should be avoided is to add/remove features in the same release. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715725#comment-17715725 ] Romain Manni-Bucau commented on DELTASPIKE-1434: The main issue is migrating away from it means doing yourself part of it since there is no real alternative in CDI land (microprofile is insanely unstable and doesnt cover 60% of DS) so tempted to say it depends what you use. For your information there are discussions on what should be kept for v2 (jakarta) or not on the list. As usual it is easy to say to the OSS "do my job" but the idea is more "join and help" so you are both welcome to join the list and do PR to make it move faster. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715722#comment-17715722 ] Thomas Andraschko commented on DELTASPIKE-1434: --- 100% of the still active commiters maintains multiple Java/JakartaEE projects on apache here, DeltaSpike is just that with the lowest prio for us. We first try to get all other libs running again, so we have "our" application server (TomEE) before we can even use DeltaSpike again. Its not an easy task to migrate like 15 libs from javax to jakarta. We need at least some tests running on real containers, everyone can help here migrating the tests. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715695#comment-17715695 ] Krzysztof Wolny commented on DELTASPIKE-1434: - +1 for [~romanmueller] , it's a bit of shame that after 2 years it's still not migrated to Jakarta. Maybe this project is simply dying and we should migrate out of it. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715601#comment-17715601 ] Roman Müller commented on DELTASPIKE-1434: -- Consider migrating away from Deltaspike. It is not that much value it adds to your project anyway tbh. We did it for our project and it only took 2 weeks. Way faster than making Deltaspike compatible with Jakarta. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715306#comment-17715306 ] Romain Manni-Bucau commented on DELTASPIKE-1434: The harm would be to just deliver soemthing broken and imply people keep investing time in pure lost, we dont work like that. As of today arquillian is partially ready so question is the container coverage we want. I guess payara, tomee, maybe wildfly (less sure today). Feel free to help to uodate the setup Jeremy to make it move faster. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715179#comment-17715179 ] Jeremy Landis commented on DELTASPIKE-1434: --- Can we just old school this and release 2.0 milestone? Total blocker otherwise. I mean what's the harm in doing so? Those of us that keep asking are willing to real world test it. Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg> > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714994#comment-17714994 ] Thomas Andraschko commented on DELTASPIKE-1434: --- our integrationtests are built to run on different javax containers in 1.x noone tried to migrate those to jakarta containers yet, even not sure if arquillian is ready etc. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714982#comment-17714982 ] Krzysztof Wolny commented on DELTASPIKE-1434: - Not sure if I got your second sentence. Do you say you don't have enough automated integration tests and you need help to test it manually somehow? > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714964#comment-17714964 ] Thomas Andraschko commented on DELTASPIKE-1434: --- i migrated most of the modules to jakarta last month but we still dont have running integration tests if you have time to get all tests running on recent containers, i can help on fixing the tests. > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1434) Namespace change javax to jakarta
[ https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714921#comment-17714921 ] Krzysztof Wolny commented on DELTASPIKE-1434: - Any update on the timeline? It's a blocker for us. This change started in 2021, it's 2023 and it's not finished :( > Namespace change javax to jakarta > - > > Key: DELTASPIKE-1434 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: John Smith >Assignee: Mark Struberg >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > > Is there a plan to make the namespace change from javax to jakartaee. Seems > to be required to use deltaspike in the future. > https://jakarta.ee/compatibility/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (DELTASPIKE-1434) Namespace change javax to jakarta
[
https://issues.apache.org/jira/browse/DELTASPIKE-1434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714921#comment-17714921
]
Krzysztof Wolny edited comment on DELTASPIKE-1434 at 4/21/23 9:51 AM:
--
Any update on the timeline? It's a blocker for us. This change started in 2021,
it's 2023 and it's not finished :( {{2.0-snapshot}} version is released and
working.
was (Author: vanta):
Any update on the timeline? It's a blocker for us. This change started in 2021,
it's 2023 and it's not finished :(
> Namespace change javax to jakarta
> -
>
> Key: DELTASPIKE-1434
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1434
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: Core
>Affects Versions: 1.9.5
>Reporter: John Smith
>Assignee: Mark Struberg
>Priority: Major
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> Is there a plan to make the namespace change from javax to jakartaee. Seems
> to be required to use deltaspike in the future.
> https://jakarta.ee/compatibility/
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1449) Broken quartz annotations and duplicate job details
[
https://issues.apache.org/jira/browse/DELTASPIKE-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714566#comment-17714566
]
Gary Hodgson commented on DELTASPIKE-1449:
--
Hi, we just hit the quartz annotations part of this bug after updating from
1.9.0 to 1.9.6.
As Michel states it was introduced in
https://github.com/apache/deltaspike/pull/84, if I understand the code
correctly, with the introduction of the
[JobAdapter|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/impl/src/main/java/org/apache/deltaspike/scheduler/impl/JobAdapter.java]
class.
This is used by the default org.apache.deltaspike.scheduler.spi.Scheduler:
[JobQuartzScheduler|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/impl/src/main/java/org/apache/deltaspike/scheduler/impl/JobQuartzScheduler.java]
for the FinalJobClass which in turn the
[AbstractQuartzScheduler|https://github.com/apache/deltaspike/blob/master/deltaspike/modules/scheduler/impl/src/main/java/org/apache/deltaspike/scheduler/impl/AbstractQuartzScheduler.java#L192]
uses to specify the JobClass in JobDetail.
[org.quartz.impl.JobDetailImpl#isConcurrentExectionDisallowed|https://github.com/quartz-scheduler/quartz/blob/quartz-2.3.x/quartz-core/src/main/java/org/quartz/impl/JobDetailImpl.java#L386]
then looks for the DisallowConcurrentExecution annotation on the jobClass to
determine if concurrent exection is disallowed:
{code:java}
public boolean isConcurrentExectionDisallowed() {
return ClassUtils.isAnnotationPresent(jobClass,
DisallowConcurrentExecution.class);
}
{code}
So far I can't see the use of the JobAdapter class at all, and when I created a
simple test JobQuartzScheduler which returns the original class name:
{code:java}
public class MyJobQuartzScheduler extends AbstractQuartzScheduler {
...
@Override
protected Class createFinalJobClass(Class
jobClass) {
return jobClass;
}
{code}
the annotations are found and the regression is gone.
> Broken quartz annotations and duplicate job details
> ---
>
> Key: DELTASPIKE-1449
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1449
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: Scheduler
>Affects Versions: 1.9.1
>Reporter: Michel Zedler
>Priority: Major
>
> This exemplary job class
> {code:java}
> package my.package
> import org.apache.deltaspike.scheduler.api.Scheduled;
> import org.quartz.DisallowConcurrentExecution;
> import org.quartz.Job;
> @Scheduled(cronExpression = "...", overrideOnStartup = true)
> @DisallowConcurrentExecution
> public class MyJob implements Job {
> ...
> } {code}
> using deltaspike 1.9.0 results in:
> {noformat}
> table: QRTZ_JOB_DETAILS
> row 1:
> JOB_NAME = MyJob
> JOB_CLASS_NAME = my.package.MyJob
> IS_NONCONCURRENT = 1 (true){noformat}
> using deltaspike 1.9.1 or later
> + a previously empty table results in:
> {noformat}
> table: QRTZ_JOB_DETAILS
> row 1:
> JOB_NAME = my.package.MyJob
> JOB_CLASS_NAME = org.apache.deltaspike.scheduler.impl.JobAdapter
> IS_NONCONCURRENT = 0 (false){noformat}
> + a non-empty table results in:
> {noformat}
> table: QRTZ_JOB_DETAILS
> row 1: (inserted by a deployment using 1.9.0 or earlier)
> JOB_NAME = MyJob
> JOB_CLASS_NAME = my.package.MyJob
> IS_NONCONCURRENT = 1 (true)
> row 2:
> JOB_NAME = my.package.MyJob
> JOB_CLASS_NAME = org.apache.deltaspike.scheduler.impl.JobAdapter
> IS_NONCONCURRENT = 0 (false){noformat}
>
> I tracked this behaviour down to changes by DELTASPIKE-1369 that were
> released with 1.9.1
> causing:
> (1) annotations org.quartz.DisallowConcurrentExecution and
> org.quartz.PersistJobDataAfterExecution to be effectively ignored because
> Quartz checks for their presence in class
> org.apache.deltaspike.scheduler.impl.JobAdapter.
> (2) consecutive deployments to produce duplicate job details.
> I could not find any release notes, migration guides or open bugs or fixes
> concerning this topic.
> Expected behaviour:
> * deltaspike/quartz should update existing JobDetails instead of inserting
> duplicates
> (JOB_CLASS_NAME of existing job details can be matched to new JOB_NAME - both
> are the fully qualified class name)
> * functionality of quartz annotations should be restored
> I can provide more context if useful.
> Are there any known workarounds?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (DELTASPIKE-1462) Rename jsf to faces and jpa to persistence
[ https://issues.apache.org/jira/browse/DELTASPIKE-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko closed DELTASPIKE-1462. - Fix Version/s: (was: 2.0) Resolution: Won't Fix > Rename jsf to faces and jpa to persistence > -- > > Key: DELTASPIKE-1462 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1462 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: Thomas Andraschko >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DELTASPIKE-1234) DS 2: check if we can remove our proxy module
[ https://issues.apache.org/jira/browse/DELTASPIKE-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko closed DELTASPIKE-1234. - Fix Version/s: (was: 2.0) Resolution: Won't Fix > DS 2: check if we can remove our proxy module > - > > Key: DELTASPIKE-1234 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1234 > Project: DeltaSpike > Issue Type: Bug > Components: Proxy-Module >Affects Versions: 2.0 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > > in favor of the InterceptionFactory > This will likely not work because we also support abstract classes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1443) deltaspike-cdictrl-weld depends on junit
[
https://issues.apache.org/jira/browse/DELTASPIKE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707276#comment-17707276
]
Björn Kautler commented on DELTASPIKE-1443:
---
Oh, I'm sorry.
This actually seems to be a bug in the Gradle resolution engine.
It seems it does not take into account the {{}} coming from the
{{}}.
> deltaspike-cdictrl-weld depends on junit
>
>
> Key: DELTASPIKE-1443
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1443
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 1.9.5
>Reporter: Björn Kautler
>Priority: Major
>
> deltaspike-cdictrl-weld (and probably all modules as it is defined in parent)
> depends on junit.
> We use deltaspike-cdictrl-weld in production, so this dependency leaks junit
> into the runtime classpath.
> It should probably only be in test scope.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1443) deltaspike-cdictrl-weld depends on junit
[ https://issues.apache.org/jira/browse/DELTASPIKE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707277#comment-17707277 ] Björn Kautler commented on DELTASPIKE-1443: --- Ah, and obviously I did hit that bug again about a year after reporting this issue but at that time attributed it to the right project: [https://github.com/gradle/gradle/issues/21507] :D > deltaspike-cdictrl-weld depends on junit > > > Key: DELTASPIKE-1443 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1443 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.9.5 >Reporter: Björn Kautler >Priority: Major > > deltaspike-cdictrl-weld (and probably all modules as it is defined in parent) > depends on junit. > We use deltaspike-cdictrl-weld in production, so this dependency leaks junit > into the runtime classpath. > It should probably only be in test scope. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DELTASPIKE-1282) DeltaSpikeFacesContextWrapper leaks on TomEE
[ https://issues.apache.org/jira/browse/DELTASPIKE-1282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko closed DELTASPIKE-1282. - Fix Version/s: (was: 2.0) Resolution: Cannot Reproduce > DeltaSpikeFacesContextWrapper leaks on TomEE > > > Key: DELTASPIKE-1282 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1282 > Project: DeltaSpike > Issue Type: Bug > Components: JSF-Module >Affects Versions: 1.8.0 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1443) deltaspike-cdictrl-weld depends on junit
[ https://issues.apache.org/jira/browse/DELTASPIKE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707208#comment-17707208 ] Thomas Andraschko commented on DELTASPIKE-1443: --- mvn dependency:tree outputs [INFO] +- junit:junit:jar:4.13.2:test in trunk > deltaspike-cdictrl-weld depends on junit > > > Key: DELTASPIKE-1443 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1443 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.9.5 >Reporter: Björn Kautler >Priority: Major > > deltaspike-cdictrl-weld (and probably all modules as it is defined in parent) > depends on junit. > We use deltaspike-cdictrl-weld in production, so this dependency leaks junit > into the runtime classpath. > It should probably only be in test scope. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (DELTASPIKE-1443) deltaspike-cdictrl-weld depends on junit
[ https://issues.apache.org/jira/browse/DELTASPIKE-1443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko closed DELTASPIKE-1443. - Resolution: Cannot Reproduce > deltaspike-cdictrl-weld depends on junit > > > Key: DELTASPIKE-1443 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1443 > Project: DeltaSpike > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.9.5 >Reporter: Björn Kautler >Priority: Major > > deltaspike-cdictrl-weld (and probably all modules as it is defined in parent) > depends on junit. > We use deltaspike-cdictrl-weld in production, so this dependency leaks junit > into the runtime classpath. > It should probably only be in test scope. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DELTASPIKE-1435) dsrwid cookie should not be set to sameSite="None" - again
[
https://issues.apache.org/jira/browse/DELTASPIKE-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko resolved DELTASPIKE-1435.
---
Resolution: Fixed
> dsrwid cookie should not be set to sameSite="None" - again
> --
>
> Key: DELTASPIKE-1435
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1435
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 1.9.5
>Reporter: Juri Berlanda
>Priority: Major
> Fix For: 2.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Very similar to DELTASPIKE-1413, this refers to the missing {{SameSite}}
> attribute in {{windowhandler.js}}
> (https://github.com/apache/deltaspike/blob/deltaspike-1.9.5/deltaspike/modules/jsf/impl/src/main/resources/META-INF/resources/deltaspike/windowhandler.js#L619)
> This means, that the following warning still appears in Firefox (tested on
> 90.0.2):
> {quote}Cookie “dsrwid-326” will be soon rejected because it has the
> “SameSite” attribute set to “None” or an invalid value, without the “secure”
> attribute. To know more about the “SameSite“ attribute, read
> https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite
> windowhandler.js.xhtml:17:364{quote}
> Now, I'd propose to set the cookie to {{SameSite=Strict}} here, too. PR is in
> the works.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (DELTASPIKE-1428) Empty resolvedComponents not cached in InjectionResolver
[ https://issues.apache.org/jira/browse/DELTASPIKE-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko closed DELTASPIKE-1428. - Resolution: Won't Fix we removed the injection wrapping in favor of native JSF 2.3+ injection feature > Empty resolvedComponents not cached in InjectionResolver > > > Key: DELTASPIKE-1428 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1428 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) > Components: Core >Affects Versions: 1.9.5 >Reporter: Vladimir Dvorak >Priority: Minor > > Issue was reported originally repoted as an OWB problem: > https://issues.apache.org/jira/browse/OWB-1381 > but was shown the problem is in DS, reproducible example is at: > [https://github.com/skybber/pf-expensive-converter|http://example.com/] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (DELTASPIKE-1323) upgrade maven-bundle-plugin to more recent version
[ https://issues.apache.org/jira/browse/DELTASPIKE-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko reassigned DELTASPIKE-1323: - Assignee: Mark Struberg > upgrade maven-bundle-plugin to more recent version > -- > > Key: DELTASPIKE-1323 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1323 > Project: DeltaSpike > Issue Type: Task > Components: Build >Affects Versions: 1.9.0 >Reporter: Mark Struberg >Assignee: Mark Struberg >Priority: Major > > we currently use a very old OSGi bundle plugin version which doesn't work > with Java8 constructs. > > I've tried to update to any more recent version but failed. My OSGi mojo is > not strong enough. > maven-bundle-plugin 2.5.0 complains about wrong imports and any more recent > version (e.g. 3.5.0) totally breaks the compilation. > > The only workaround I found so far is to switch from 'bundle' to 'jar' > packaging. > > Would be great if someone with OSGi knowledge could take a look at it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (DELTASPIKE-1406) Usage of "SHA-256" and "AES" is insecure
[
https://issues.apache.org/jira/browse/DELTASPIKE-1406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko reassigned DELTASPIKE-1406:
-
Assignee: Mark Struberg
> Usage of "SHA-256" and "AES" is insecure
>
>
> Key: DELTASPIKE-1406
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1406
> Project: DeltaSpike
> Issue Type: Improvement
> Security Level: public(Regular issues)
>Reporter: Md Mahir Asef Kabir
>Assignee: Mark Struberg
>Priority: Major
>
> *Vulnerability Description:* In
> “deltaspike/core/impl/src/main/java/org/apache/deltaspike/core/impl/crypto/DefaultCipherService.java”,
> the following algorithms were set to use later -
> {code:java}
> private static final String HASH_ALGORITHM = "SHA-256";
> private static final String CIPHER_ALGORITHM = "AES";
> {code}
> Here, SHA-256 and AES are vulnerable.
> *Reason it’s vulnerable:* According to
> [this|https://soylentnews.org/article.pl?sid=19/09/10/2351241], SHA256 can be
> broken.
> ”AES” is also not secure. For further reference, please follow
> [this|https://zachgrace.com/posts/attacking-ecb/]
> *Suggested Fix:* The secure algorithms to set would be -
> {code:java}
> private static final String HASH_ALGORITHM = "SHA-512";
> private static final String CIPHER_ALGORITHM = "AES/CFB/PKCS5Padding";
> {code}
> *Feedback:* Please select any of the options down below to help us get an
> idea about how you felt about the suggestion -
> # Liked it and will make the suggested changes
> # Liked it but happy with the existing version
> # Didn’t find the suggestion helpful
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1435) dsrwid cookie should not be set to sameSite="None" - again
[
https://issues.apache.org/jira/browse/DELTASPIKE-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707193#comment-17707193
]
ASF subversion and git services commented on DELTASPIKE-1435:
-
Commit 124c037c9dad77f0eea0b2deee06ad5331bb1719 in deltaspike's branch
refs/heads/master from Thomas Andraschko
[ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=124c037c9 ]
Merge pull request #118 from j-be/jbe-DELTASPIKE-1435
DELTASPIKE-1435 Add SameSite=Strict to windowhandler.js
> dsrwid cookie should not be set to sameSite="None" - again
> --
>
> Key: DELTASPIKE-1435
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1435
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 1.9.5
>Reporter: Juri Berlanda
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Very similar to DELTASPIKE-1413, this refers to the missing {{SameSite}}
> attribute in {{windowhandler.js}}
> (https://github.com/apache/deltaspike/blob/deltaspike-1.9.5/deltaspike/modules/jsf/impl/src/main/resources/META-INF/resources/deltaspike/windowhandler.js#L619)
> This means, that the following warning still appears in Firefox (tested on
> 90.0.2):
> {quote}Cookie “dsrwid-326” will be soon rejected because it has the
> “SameSite” attribute set to “None” or an invalid value, without the “secure”
> attribute. To know more about the “SameSite“ attribute, read
> https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite
> windowhandler.js.xhtml:17:364{quote}
> Now, I'd propose to set the cookie to {{SameSite=Strict}} here, too. PR is in
> the works.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DELTASPIKE-1435) dsrwid cookie should not be set to sameSite="None" - again
[
https://issues.apache.org/jira/browse/DELTASPIKE-1435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Andraschko updated DELTASPIKE-1435:
--
Fix Version/s: 2.0
> dsrwid cookie should not be set to sameSite="None" - again
> --
>
> Key: DELTASPIKE-1435
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1435
> Project: DeltaSpike
> Issue Type: Bug
> Security Level: public(Regular issues)
>Affects Versions: 1.9.5
>Reporter: Juri Berlanda
>Priority: Major
> Fix For: 2.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Very similar to DELTASPIKE-1413, this refers to the missing {{SameSite}}
> attribute in {{windowhandler.js}}
> (https://github.com/apache/deltaspike/blob/deltaspike-1.9.5/deltaspike/modules/jsf/impl/src/main/resources/META-INF/resources/deltaspike/windowhandler.js#L619)
> This means, that the following warning still appears in Firefox (tested on
> 90.0.2):
> {quote}Cookie “dsrwid-326” will be soon rejected because it has the
> “SameSite” attribute set to “None” or an invalid value, without the “secure”
> attribute. To know more about the “SameSite“ attribute, read
> https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite
> windowhandler.js.xhtml:17:364{quote}
> Now, I'd propose to set the cookie to {{SameSite=Strict}} here, too. PR is in
> the works.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1464) Use jfwid over dswid
[ https://issues.apache.org/jira/browse/DELTASPIKE-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707185#comment-17707185 ] ASF subversion and git services commented on DELTASPIKE-1464: - Commit 39b8c68fb4b9f817ce34490f56f6374b55319172 in deltaspike's branch refs/heads/master from Thomas Andraschko [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=39b8c68fb ] DELTASPIKE-1464 > Use jfwid over dswid > > > Key: DELTASPIKE-1464 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1464 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: Thomas Andraschko >Priority: Major > Fix For: 2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DELTASPIKE-1464) Use jfwid over dswid
[ https://issues.apache.org/jira/browse/DELTASPIKE-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Andraschko resolved DELTASPIKE-1464. --- Resolution: Fixed > Use jfwid over dswid > > > Key: DELTASPIKE-1464 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1464 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: Thomas Andraschko >Priority: Major > Fix For: 2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DELTASPIKE-1464) Use jfwid over dswid
[ https://issues.apache.org/jira/browse/DELTASPIKE-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17707172#comment-17707172 ] ASF subversion and git services commented on DELTASPIKE-1464: - Commit a5a95c9aec28339a688bcb83cf8508425408768c in deltaspike's branch refs/heads/master from Thomas Andraschko [ https://gitbox.apache.org/repos/asf?p=deltaspike.git;h=a5a95c9ae ] DELTASPIKE-1464 > Use jfwid over dswid > > > Key: DELTASPIKE-1464 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1464 > Project: DeltaSpike > Issue Type: Improvement > Security Level: public(Regular issues) >Reporter: Thomas Andraschko >Priority: Major > Fix For: 2.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
