[JBoss JIRA] (ELY-1577) Wildfly Elytron Tool, location is required even for non-filebased type e.g. PKCS11
by Ilia Vassilev (JIRA)
Ilia Vassilev created ELY-1577:
----------------------------------
Summary: Wildfly Elytron Tool, location is required even for non-filebased type e.g. PKCS11
Key: ELY-1577
URL: https://issues.jboss.org/browse/ELY-1577
Project: WildFly Elytron
Issue Type: Bug
Components: Command-Line Tool
Affects Versions: 1.3.1.Final
Reporter: Ilia Vassilev
Assignee: Ilia Vassilev
Wildfly Elytron tool is not aligned with fix for ELY-1460 - Do not reuse location attribute for externalPath attribute. Make externalPath required when external configured.
In Wildfly Elytron tool location is mandatory
{code:java|title=CredentialStoreCommand.java}
String location = cmdLine.getOptionValue(STORE_LOCATION_PARAM);
if (location == null) {
setStatus(GENERAL_CONFIGURATION_ERROR);
throw ElytronToolMessages.msg.optionNotSpecified(STORE_LOCATION_PARAM);
}
{code:java|title=CredentialStoreCommand.java}
After relaxing this check, double check usage of location, e.g. here
{code}
if ((cmdLine.hasOption(ALIASES_PARAM) || cmdLine.hasOption(CHECK_ALIAS_PARAM)) && !Files.exists(Paths.get(location))) {
setStatus(GENERAL_CONFIGURATION_ERROR);
throw ElytronToolMessages.msg.storageFileDoesNotExist(location);
}
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-1576) Wildfly Elytron Tool, location is required even for non-filebased type e.g. PKCS11
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1576?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1576:
----------------------------------
Assignee: Ilia Vassilev
> Wildfly Elytron Tool, location is required even for non-filebased type e.g. PKCS11
> ----------------------------------------------------------------------------------
>
> Key: ELY-1576
> URL: https://issues.jboss.org/browse/ELY-1576
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Command-Line Tool
> Affects Versions: 1.3.1.Final
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
>
> Wildfly Elytron tool is not aligned with fix for ELY-1460 - Do not reuse location attribute for externalPath attribute. Make externalPath required when external configured.
> In Wildfly Elytron tool location is mandatory
> {code:java|title=CredentialStoreCommand.java}
> String location = cmdLine.getOptionValue(STORE_LOCATION_PARAM);
> if (location == null) {
> setStatus(GENERAL_CONFIGURATION_ERROR);
> throw ElytronToolMessages.msg.optionNotSpecified(STORE_LOCATION_PARAM);
> }
> {code:java|title=CredentialStoreCommand.java}
> After relaxing this check, double check usage of location, e.g. here
> {code}
> if ((cmdLine.hasOption(ALIASES_PARAM) || cmdLine.hasOption(CHECK_ALIAS_PARAM)) && !Files.exists(Paths.get(location))) {
> setStatus(GENERAL_CONFIGURATION_ERROR);
> throw ElytronToolMessages.msg.storageFileDoesNotExist(location);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-1460) External CS, PKCS11 can't be configured with externalPath
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1460?page=com.atlassian.jira.plugin.s... ]
Martin Choma commented on ELY-1460:
-----------------------------------
[~ivassile], sure ELY-1576. I have created in ELY project and component Command-Line Tool. Hope it fits there.
> External CS, PKCS11 can't be configured with externalPath
> ----------------------------------------------------------
>
> Key: ELY-1460
> URL: https://issues.jboss.org/browse/ELY-1460
> Project: WildFly Elytron
> Issue Type: Bug
> Components: KeyStores
> Affects Versions: 1.2.0.Beta10
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
> Priority: Critical
> Fix For: 1.2.0.Beta12
>
>
> To specify external secret file location externalPath is intended. However in case of PKCS11 it can't be achieved.
> {code}
> 10:53:03,403 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.credential-store.fips-credential-store: org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.fips-credential-store: WFLYELY00004: Unable to start the service.
> at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:134)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:954)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:828)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:214)
> at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:159)
> at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:126)
> ... 5 more
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store
> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel(Files.java:361)
> at java.nio.file.Files.newByteChannel(Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream(Files.java:152)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:943)
> ... 9 more
> 10:53:03,409 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("credential-store" => "fips-credential-store")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.fips-credential-store" => "WFLYELY00004: Unable to start the service.
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store"}}
> {code}
> Problem seems to be in method
> {code:java|title=KeyStoreCredentialStore.java}
> private void setupExternalStorage(final String keyContainingKeyStoreType, final Path keyContainingKeyStoreLocation) throws CredentialStoreException {
> KeyStore keyContainingKeyStore = getKeyStoreInstance(keyContainingKeyStoreType);
> keyStore = getKeyStoreInstance("JCEKS");
> externalStorage = new ExternalStorage();
> try {
> final char[] storePassword = getStorePassword(protectionParameter);
> if (keyContainingKeyStoreLocation != null) {
> try (InputStream is = Files.newInputStream(keyContainingKeyStoreLocation)) {
> keyContainingKeyStore.load(is, storePassword);
> }
> } else {
> // keystore without file (e.g. PKCS11)
> synchronized (EmptyProvider.getInstance()) {
> keyContainingKeyStore.load(null, storePassword);
> }
> }
> externalStorage.init(cryptographicAlgorithm, encryptionKeyAlias, keyContainingKeyStore, storePassword, keyStore);
> } catch(IOException | GeneralSecurityException e) {
> throw log.cannotInitializeCredentialStore(e);
> }
> }
> {code}
> Although location is not specified in CLI command keyContainingKeyStoreLocation is not null. Because once location is not specified it becomes name of CS, in this case fips-credential-store (This default is in elytron subsystem).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-1576) Location is required even for non-filebased type e.g. PKCS11
by Martin Choma (JIRA)
Martin Choma created ELY-1576:
---------------------------------
Summary: Location is required even for non-filebased type e.g. PKCS11
Key: ELY-1576
URL: https://issues.jboss.org/browse/ELY-1576
Project: WildFly Elytron
Issue Type: Bug
Components: Command-Line Tool
Affects Versions: 1.3.1.Final
Reporter: Martin Choma
Wildfly Elytron tool is not aligned with fix for ELY-1460 - Do not reuse location attribute for externalPath attribute. Make externalPath required when external configured.
In Wildfly Elytron tool location is mandatory
{code:java|title=CredentialStoreCommand.java}
String location = cmdLine.getOptionValue(STORE_LOCATION_PARAM);
if (location == null) {
setStatus(GENERAL_CONFIGURATION_ERROR);
throw ElytronToolMessages.msg.optionNotSpecified(STORE_LOCATION_PARAM);
}
{code:java|title=CredentialStoreCommand.java}
After relaxing this check, double check usage of location, e.g. here
{code}
if ((cmdLine.hasOption(ALIASES_PARAM) || cmdLine.hasOption(CHECK_ALIAS_PARAM)) && !Files.exists(Paths.get(location))) {
setStatus(GENERAL_CONFIGURATION_ERROR);
throw ElytronToolMessages.msg.storageFileDoesNotExist(location);
}
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-1576) Wildfly Elytron Tool, location is required even for non-filebased type e.g. PKCS11
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-1576?page=com.atlassian.jira.plugin.s... ]
Martin Choma updated ELY-1576:
------------------------------
Summary: Wildfly Elytron Tool, location is required even for non-filebased type e.g. PKCS11 (was: Location is required even for non-filebased type e.g. PKCS11)
> Wildfly Elytron Tool, location is required even for non-filebased type e.g. PKCS11
> ----------------------------------------------------------------------------------
>
> Key: ELY-1576
> URL: https://issues.jboss.org/browse/ELY-1576
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Command-Line Tool
> Affects Versions: 1.3.1.Final
> Reporter: Martin Choma
>
> Wildfly Elytron tool is not aligned with fix for ELY-1460 - Do not reuse location attribute for externalPath attribute. Make externalPath required when external configured.
> In Wildfly Elytron tool location is mandatory
> {code:java|title=CredentialStoreCommand.java}
> String location = cmdLine.getOptionValue(STORE_LOCATION_PARAM);
> if (location == null) {
> setStatus(GENERAL_CONFIGURATION_ERROR);
> throw ElytronToolMessages.msg.optionNotSpecified(STORE_LOCATION_PARAM);
> }
> {code:java|title=CredentialStoreCommand.java}
> After relaxing this check, double check usage of location, e.g. here
> {code}
> if ((cmdLine.hasOption(ALIASES_PARAM) || cmdLine.hasOption(CHECK_ALIAS_PARAM)) && !Files.exists(Paths.get(location))) {
> setStatus(GENERAL_CONFIGURATION_ERROR);
> throw ElytronToolMessages.msg.storageFileDoesNotExist(location);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-1572) japicmp force source compatibility, but only binary compatibility is required
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1572?page=com.atlassian.jira.plugin.s... ]
Jan Kalina edited comment on ELY-1572 at 5/4/18 8:01 AM:
---------------------------------------------------------
In future, we can re-enable source compatibility check and ignore adding default methods into interfaces only:
{code}
<plugin>
<groupId>com.github.siom79.japicmp</groupId>
<artifactId>japicmp-maven-plugin</artifactId>
- <version>0.11.0</version>
+ <version>0.12.1-SNAPSHOT</version>
<configuration>
@@ -568,7 +568,21 @@
<parameter>
<breakBuildOnBinaryIncompatibleModifications>true</breakBuildOnBinaryIncompatibleModifications>
- <breakBuildOnSourceIncompatibleModifications>false</breakBuildOnSourceIncompatibleModifications>
+ <breakBuildOnSourceIncompatibleModifications>true</breakBuildOnSourceIncompatibleModifications>
+ <overrideCompatibilityChangeParameters>
+ <overrideCompatibilityChangeParameter>
+ <compatibilityChange>METHOD_NEW_DEFAULT</compatibilityChange>
+ <binaryCompatible>true</binaryCompatible>
+ <sourceCompatible>true</sourceCompatible>
+ </overrideCompatibilityChangeParameter>
+ </overrideCompatibilityChangeParameters>
{code}
But this depends on last japicmp version - possible only after releasing japicmp 0.12.1.
was (Author: honza889):
In future, we can re-enable source compatibility check and ignore adding default methods into interfaces only:
{code}
<plugin>
<groupId>com.github.siom79.japicmp</groupId>
<artifactId>japicmp-maven-plugin</artifactId>
- <version>0.11.0</version>
+ <version>0.12.1-SNAPSHOT</version>
<configuration>
@@ -568,7 +568,21 @@
<parameter>
<breakBuildOnBinaryIncompatibleModifications>true</breakBuildOnBinaryIncompatibleModifications>
- <breakBuildOnSourceIncompatibleModifications>false</breakBuildOnSourceIncompatibleModifications>
+ <breakBuildOnSourceIncompatibleModifications>true</breakBuildOnSourceIncompatibleModifications>
+ <overrideCompatibilityChangeParameters>
+ <overrideCompatibilityChangeParameter>
+ <compatibilityChange>METHOD_NEW_DEFAULT</compatibilityChange>
+ <binaryCompatible>true</binaryCompatible>
+ <sourceCompatible>true</sourceCompatible>
+ </overrideCompatibilityChangeParameter>
+ </overrideCompatibilityChangeParameters>
{code}
But currently there is still bug (https://github.com/siom79/japicmp/issues/201#issuecomment-386222564), so METHOD_ADDED_TO_INTERFACE would have to be ignored too -> keeping source compatibility check disabled.
> japicmp force source compatibility, but only binary compatibility is required
> -----------------------------------------------------------------------------
>
> Key: ELY-1572
> URL: https://issues.jboss.org/browse/ELY-1572
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Build
> Affects Versions: 1.3.0.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> As part of ELY-1523 japicmp was configured to force binary and source compatibility.
> By last discussion, only binary compatibility is required.
> {panel}
> *Honza Kalina* jaspicmp reports it as source incompatibility, not as binary incompatibility - so it maybe it is false positive, as I would say it should be source-compatible...
> *Darran Lofthouse* Binary is the only one we are really interested in, i.e. will an update to a later version of Elytron break something. Most of our backwards compatibility strategy is more about breaking things and upsetting people
> {panel}
> Japicmp currently reports adding default method into interface as source incompatible change (see https://github.com/siom79/japicmp/issues/201) -> blocks adding IV into MaskedPassword in ELY-867
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (ELY-1460) External CS, PKCS11 can't be configured with externalPath
by Ilia Vassilev (JIRA)
[ https://issues.jboss.org/browse/ELY-1460?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev commented on ELY-1460:
------------------------------------
[~mchoma] Can you open jira for the Elytron Tool issue and assign it to me? I need to clone it to JBEAP because most likely the change will go into CP. Thanks!
> External CS, PKCS11 can't be configured with externalPath
> ----------------------------------------------------------
>
> Key: ELY-1460
> URL: https://issues.jboss.org/browse/ELY-1460
> Project: WildFly Elytron
> Issue Type: Bug
> Components: KeyStores
> Affects Versions: 1.2.0.Beta10
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
> Priority: Critical
> Fix For: 1.2.0.Beta12
>
>
> To specify external secret file location externalPath is intended. However in case of PKCS11 it can't be achieved.
> {code}
> 10:53:03,403 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.security.credential-store.fips-credential-store: org.jboss.msc.service.StartException in service org.wildfly.security.credential-store.fips-credential-store: WFLYELY00004: Unable to start the service.
> at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:134)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:954)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.load(KeyStoreCredentialStore.java:828)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.initialize(KeyStoreCredentialStore.java:214)
> at org.wildfly.security.credential.store.CredentialStore.initialize(CredentialStore.java:159)
> at org.wildfly.extension.elytron.CredentialStoreService.start(CredentialStoreService.java:126)
> ... 5 more
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store
> at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> at java.nio.file.Files.newByteChannel(Files.java:361)
> at java.nio.file.Files.newByteChannel(Files.java:407)
> at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
> at java.nio.file.Files.newInputStream(Files.java:152)
> at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.setupExternalStorage(KeyStoreCredentialStore.java:943)
> ... 9 more
> 10:53:03,409 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 4) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("credential-store" => "fips-credential-store")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"org.wildfly.security.credential-store.fips-credential-store" => "WFLYELY00004: Unable to start the service.
> Caused by: org.wildfly.security.credential.store.CredentialStoreException: ELY09514: Unable to initialize credential store
> Caused by: java.nio.file.NoSuchFileException: /home/mchoma/workspace/git-repositories/tests-security/fips/fips-credential-store"}}
> {code}
> Problem seems to be in method
> {code:java|title=KeyStoreCredentialStore.java}
> private void setupExternalStorage(final String keyContainingKeyStoreType, final Path keyContainingKeyStoreLocation) throws CredentialStoreException {
> KeyStore keyContainingKeyStore = getKeyStoreInstance(keyContainingKeyStoreType);
> keyStore = getKeyStoreInstance("JCEKS");
> externalStorage = new ExternalStorage();
> try {
> final char[] storePassword = getStorePassword(protectionParameter);
> if (keyContainingKeyStoreLocation != null) {
> try (InputStream is = Files.newInputStream(keyContainingKeyStoreLocation)) {
> keyContainingKeyStore.load(is, storePassword);
> }
> } else {
> // keystore without file (e.g. PKCS11)
> synchronized (EmptyProvider.getInstance()) {
> keyContainingKeyStore.load(null, storePassword);
> }
> }
> externalStorage.init(cryptographicAlgorithm, encryptionKeyAlias, keyContainingKeyStore, storePassword, keyStore);
> } catch(IOException | GeneralSecurityException e) {
> throw log.cannotInitializeCredentialStore(e);
> }
> }
> {code}
> Although location is not specified in CLI command keyContainingKeyStoreLocation is not null. Because once location is not specified it becomes name of CS, in this case fips-credential-store (This default is in elytron subsystem).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-5537) Singleton EJBs with multiple views does not honor Lock semantics
by dhinckle (JIRA)
[ https://issues.jboss.org/browse/WFLY-5537?page=com.atlassian.jira.plugin.... ]
dhinckle commented on WFLY-5537:
--------------------------------
Never mind my previous comment. I misunderstood how read and write locks work with singletons. A read cannot execute while a write is executing.
> Singleton EJBs with multiple views does not honor Lock semantics
> ----------------------------------------------------------------
>
> Key: WFLY-5537
> URL: https://issues.jboss.org/browse/WFLY-5537
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.CR2
> Environment: 10.0.0.CR2
> Reporter: Nicky Mølholm
> Assignee: Stuart Douglas
> Labels: ejb, interceptor, singleton
> Fix For: 12.0.0.Beta1, 12.0.0.Final
>
>
> Upon method invocations to Singleton EJBs with multiple views... the *ContainerManagedConcurrencyInterceptor* randomly selects a wrong Lock (READ / WRITE).
> Here is an example:
> {code:java}
> @Singleton
> @Lock(LockType.READ)
> @Local({ GreeterSayMyName.class, GreeterSayHello.class })
> public class GreeterBean implements GreeterSayMyName, GreeterSayHello {
> @EJB
> GreeterSayMyName myself;
> @Override
> public String sayHello() {
> return "hello from " + myself.sayMyName();
> }
> @Override
> public String sayMyName() {
> return "The Greeter";
> }
> }
> public interface GreeterSayHello {
>
> String sayHello();
>
> }
> public interface GreeterSayMyName {
> String sayMyName();
> }
> {code}
> Sometimes (randomly) invoking the 'sayHello' method on this example EJB causes lock upgrade exceptions. They look like this:
> {noformat}
> 13:14:10,436 ERROR [f2PtkwmdRgaoHCdnZ7Vurg] [anonymous] [org.jboss.as.ejb3.invocation] (default task-5 f2PtkwmdRgaoHCdnZ7Vurg) WFLYEJB0034: EJB Invocation failed on component GreeterBean for method public abstract java.lang.String hello.world.GreeterSayHello.sayHello(): javax.ejb.IllegalLoopbackException: WFLYEJB0238: EJB 3.1 PFD2 4.8.5.1.1 upgrading from read to write lock is not allowed
> at org.jboss.as.ejb3.concurrency.EJBReadWriteLock.checkLoopback(EJBReadWriteLock.java:232)
> at org.jboss.as.ejb3.concurrency.EJBReadWriteLock.access$300(EJBReadWriteLock.java:40)
> {noformat}
> This happens completely randomly.
> The problem is that the interceptor only knows about one of the views' methods. At deployment time the ViewService will start the views concurrently - and the interceptorfactory only adds an interceptor instance to the interceptor context if one does not already exist.
> When the exception does NOT occur -then there is still a problem (although not visible from the code): A WRITE lock is selected - even though , given the above code, it should never ever be possible. So in fact - the issue , in that case, does not cause an exception because .... it already has the WRITE lock.
> ( When the exception occurs ...then it is because the sayHello() invocation resulted in a READ lock ... and the reentrant invocation caused a WRITE lock to be selected by the interceptor ... but as this is not allowed, it results in a horrible exception )
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-5537) Singleton EJBs with multiple views does not honor Lock semantics
by dhinckle (JIRA)
[ https://issues.jboss.org/browse/WFLY-5537?page=com.atlassian.jira.plugin.... ]
dhinckle commented on WFLY-5537:
--------------------------------
I am still seeing a problem related to this fix. I have installed WF 12.0.0.Final but I noticed the file dates are slightly earlier than Jason Greene's comment on 1/Mar/18 1:16 AM. I do not know if the [ 12336563 ] is a build even newer than the released version. Below is an explanation of my problem:
I get the following log on WF 12.0.0.Final:
2018-05-04 11:45:55,948 ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component OfflineBalanceSingleton for method public abstract boolean com.xxx.expand.persistence.OfflineBalanceLocal.isValid() throws com.xxx.expand.dataProcessing.reporting.SwitchException: javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0241: EJB 3.1 PFD2 4.8.5.5.1 concurrent access timeout on OfflineBalanceSingleton - could not obtain lock within 5000MILLISECONDS
This is my Singleton and notice that it is also a Timer:
...
@DependsOn({AlarmUtilLocal.SINGLETON_NAME, DataDictionarySingletonLocal.SINGLETON_NAME, ExpandLoggerLocal.SINGLETON_NAME, ServerLocal.SINGLETON_NAME})
@Singleton(name = OfflineBalanceLocal.SINGLETON_NAME)
@Startup
@TransactionManagement(TransactionManagementType.BEAN)
public class OfflineBalance2 extends TimerServiceBase implements OfflineBalanceLocal, TimedObject, TimerServiceLocal {
...
@Lock(LockType.READ)
@Override
public boolean isValid() throws SwitchException {
return isWithinValidTime(creationTime.get());
}
Notice that the log error says it couldn't obtain a lock on isValid but it is marked as READ. This does not happen often in the logs, but to my understanding it should never happen.
> Singleton EJBs with multiple views does not honor Lock semantics
> ----------------------------------------------------------------
>
> Key: WFLY-5537
> URL: https://issues.jboss.org/browse/WFLY-5537
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.0.0.CR2
> Environment: 10.0.0.CR2
> Reporter: Nicky Mølholm
> Assignee: Stuart Douglas
> Labels: ejb, interceptor, singleton
> Fix For: 12.0.0.Beta1, 12.0.0.Final
>
>
> Upon method invocations to Singleton EJBs with multiple views... the *ContainerManagedConcurrencyInterceptor* randomly selects a wrong Lock (READ / WRITE).
> Here is an example:
> {code:java}
> @Singleton
> @Lock(LockType.READ)
> @Local({ GreeterSayMyName.class, GreeterSayHello.class })
> public class GreeterBean implements GreeterSayMyName, GreeterSayHello {
> @EJB
> GreeterSayMyName myself;
> @Override
> public String sayHello() {
> return "hello from " + myself.sayMyName();
> }
> @Override
> public String sayMyName() {
> return "The Greeter";
> }
> }
> public interface GreeterSayHello {
>
> String sayHello();
>
> }
> public interface GreeterSayMyName {
> String sayMyName();
> }
> {code}
> Sometimes (randomly) invoking the 'sayHello' method on this example EJB causes lock upgrade exceptions. They look like this:
> {noformat}
> 13:14:10,436 ERROR [f2PtkwmdRgaoHCdnZ7Vurg] [anonymous] [org.jboss.as.ejb3.invocation] (default task-5 f2PtkwmdRgaoHCdnZ7Vurg) WFLYEJB0034: EJB Invocation failed on component GreeterBean for method public abstract java.lang.String hello.world.GreeterSayHello.sayHello(): javax.ejb.IllegalLoopbackException: WFLYEJB0238: EJB 3.1 PFD2 4.8.5.1.1 upgrading from read to write lock is not allowed
> at org.jboss.as.ejb3.concurrency.EJBReadWriteLock.checkLoopback(EJBReadWriteLock.java:232)
> at org.jboss.as.ejb3.concurrency.EJBReadWriteLock.access$300(EJBReadWriteLock.java:40)
> {noformat}
> This happens completely randomly.
> The problem is that the interceptor only knows about one of the views' methods. At deployment time the ViewService will start the views concurrently - and the interceptorfactory only adds an interceptor instance to the interceptor context if one does not already exist.
> When the exception does NOT occur -then there is still a problem (although not visible from the code): A WRITE lock is selected - even though , given the above code, it should never ever be possible. So in fact - the issue , in that case, does not cause an exception because .... it already has the WRITE lock.
> ( When the exception occurs ...then it is because the sayHello() invocation resulted in a READ lock ... and the reentrant invocation caused a WRITE lock to be selected by the interceptor ... but as this is not allowed, it results in a horrible exception )
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months