[JBoss JIRA] (ELY-1454) Introduce CredentialStore which works like FileSystemSecurityRealm
by David Lloyd (JIRA)
David Lloyd created ELY-1454:
--------------------------------
Summary: Introduce CredentialStore which works like FileSystemSecurityRealm
Key: ELY-1454
URL: https://issues.jboss.org/browse/ELY-1454
Project: WildFly Elytron
Issue Type: Enhancement
Components: Credential Store
Reporter: David Lloyd
Priority: Minor
It would be useful and convenient to have a credential store implementation using the same techniques – and ideally the same storage format and backend – as {{FileSystemSecurityRealm}}. Creating a basic abstraction of this format might be a reasonable first step, or it might make sense to implement either the realm in terms of the credential store, or the credential store in terms of the realm.
The credential store would probably not make any use of the attributes.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-5296) public final methods should be allowed for Local and Remote Business Interface View
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-5296?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski closed WFLY-5296.
--------------------------------
Resolution: Rejected
EJB 3.2 specification says in point 4.9.6:
{panel}
The session bean class may define zero or more business methods whose signatures must follow these
rules:
(...)
* The method must not be declared as final or static.
(...)
{panel}
The issue of an exception being thrown has been addressed by WFLY-7085. From WildFly 12 you will be unable to deploy an application that does not follow the above contract. You will be provided with the information about the bean that is a problem. As a result, no exceptions will be thrown during runtime.
> public final methods should be allowed for Local and Remote Business Interface View
> -----------------------------------------------------------------------------------
>
> Key: WFLY-5296
> URL: https://issues.jboss.org/browse/WFLY-5296
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 9.0.1.Final
> Reporter: Andreas Liebscher
> Assignee: Tomasz Adamski
>
> The spec says:
> Only public methods of the bean class (and any superclasses) may be invoked through the no-interface view. Attempted invocations of methods with any other access modifiers via the no-interface view reference must result in the javax.ejb.EJBException.
> So it is not allowed to use public final methods when using no-interface view.
> But WF-9.0.1-Final does also throw an exception when using local business interface view:
> ERROR [org.jboss.as.ejb3.invocation] (default task-31) WFLYEJB0034: EJB Invocation failed on component XxxBean for method public abstract yyy: javax.ejb.EJBException: java.lang.IllegalStateException: WFLYEE0067: Method does not exist public final zzz
> With WF-8.1.0-Final this was no problem!
> What has been changed in WF-9?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFCORE-3416) User redirected with HTTP 301 instead of 302 in admin-only mode
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3416?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFCORE-3416:
------------------------------------------
I am currently experiencing a different issue that may also be improved by incorporating these changes.
If I connect my web browser over port 9990 and then subsequently enable SSL because the previous connection used a moved permanently redirect the web browser remembers this, the admin console previously loaded from port 9990 is used and the management request to port 9990 redirected to port 9993 but now it is a cross origin request so is rejected.
> User redirected with HTTP 301 instead of 302 in admin-only mode
> ---------------------------------------------------------------
>
> Key: WFCORE-3416
> URL: https://issues.jboss.org/browse/WFCORE-3416
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 4.0.0.Alpha2
> Environment: JBoss EAP 7.1.0.Alpha and 7.0.5
> OS : RHEL 7
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
>
> The issue isn't that the console isn't working in admin-only mode. It's that a permanent redirect is issued for a temporary condition. The redirect from the console root URL should use a 302, not a 301, since the appropriate target depends on whether the server was started in admin-only mode.
> The root URL of the admin console ( / ) does a permanent redirect (301) to the final target. Normally it's a redirect to /console/index.html. But if the server is started in admin-only mode then /console/index.html doesn't return a sensible error (Chrome reports that the connection to the server was lost). If a browser has cached the permanent redirect, it won't be clear why the console isn't working.
> On the other hand if the server is started in domain-only mode and the browser caches the permanent redirect to /consoleerror/noConsoleForAdminModeError.html, then the browser will continue to load /consoleerror/noConsoleForAdminModeError.html even after the server is started without --admin-only.
> A 301 redirect is inappropriate since "admin-only" isn't a permanent state.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFCORE-3396) Provide certificate authority integration
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3396?page=com.atlassian.jira.plugi... ]
Farah Juma updated WFCORE-3396:
-------------------------------
Description:
Let's Encrypt provide API to fully automate (gain/renew) certificate retrieval using ACME protocol. Integrate this capability into wildfly.
This can simplify administrator work. No need to perform certification renewal routine tasks.
This is follow up on WFCORE-3305 and piece of bigger task "Simplify SSL configuration in wildfly". That said it is just "User experience" issue. Administrator still can work with Let's Encrypt by third party client and just reference wildfly to this certificate.
[1] Latest draft: https://tools.ietf.org/html/draft-ietf-acme-acme-08
was:
Let's Encrypt provide API to fully automate (gain/renew) certificate retrieval using ACME protocol. Integrate this capability into wildfly.
This can simplify administrator work. No need to perform certification renewal routine tasks.
This is follow up on WFCORE-3305 and piece of bigger task "Simplify SSL configuration in wildfly". That said it is just "User experience" issue. Administrator still can work with Let's Encrypt by third party client and just reference wildfly to this certificate.
[1] https://tools.ietf.org/html/draft-ietf-acme-acme-07
> Provide certificate authority integration
> -----------------------------------------
>
> Key: WFCORE-3396
> URL: https://issues.jboss.org/browse/WFCORE-3396
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 4.0.0.Alpha2
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
>
> Let's Encrypt provide API to fully automate (gain/renew) certificate retrieval using ACME protocol. Integrate this capability into wildfly.
> This can simplify administrator work. No need to perform certification renewal routine tasks.
> This is follow up on WFCORE-3305 and piece of bigger task "Simplify SSL configuration in wildfly". That said it is just "User experience" issue. Administrator still can work with Let's Encrypt by third party client and just reference wildfly to this certificate.
> [1] Latest draft: https://tools.ietf.org/html/draft-ietf-acme-acme-08
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-9581) Refactor DoctypeDeclTestCase slightly to make it more similar to other tests that execute management operations and reload the server
by Farah Juma (JIRA)
Farah Juma created WFLY-9581:
--------------------------------
Summary: Refactor DoctypeDeclTestCase slightly to make it more similar to other tests that execute management operations and reload the server
Key: WFLY-9581
URL: https://issues.jboss.org/browse/WFLY-9581
Project: WildFly
Issue Type: Task
Reporter: Farah Juma
Assignee: Farah Juma
It's still unclear why {{DoctypeDeclTestCase}} fails intermittently on Windows CI with the following exception:
{code}
18:51:38,995 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0268: Failed to rename temp file C:\BuildAgent\work\5768cf3a0bee5b47\full\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone.xml.tmp to C:\BuildAgent\work\5768cf3a0bee5b47\full\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone.xml: org.jboss.as.controller.persistence.ConfigurationPersistenceException: WFLYCTL0268: Failed to rename temp file C:\BuildAgent\work\5768cf3a0bee5b47\full\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone.xml.tmp to C:\BuildAgent\work\5768cf3a0bee5b47\full\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone.xml
at org.jboss.as.controller.persistence.FilePersistenceUtils.moveTempFileToMain(FilePersistenceUtils.java:88)
at org.jboss.as.controller.persistence.ConfigurationFile.commitTempFile(ConfigurationFile.java:570)
at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:70)
at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
at org.jboss.as.controller.ModelControllerImpl$3.commit(ModelControllerImpl.java:727)
at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:838)
at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:752)
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:450)
at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:420)
at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:245)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:245)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
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)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.nio.file.FileSystemException: C:\BuildAgent\work\5768cf3a0bee5b47\full\testsuite\integration\basic\target\jbossas\standalone\configuration\standalone.xml: The process cannot access the file because it is being used by another process.
at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:376)
at sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287)
at java.nio.file.Files.move(Files.java:1395)
at org.jboss.as.controller.persistence.FilePersistenceUtils.moveTempFileToMain(FilePersistenceUtils.java:86)
... 28 more
{code}
Attempt to refactor this test slightly to make it more similar to other tests that execute management operations and reload the server to see if this has an impact on Windows CI.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2155) table editor should use full canvas area available
by Liz Clayton (JIRA)
Liz Clayton created DROOLS-2155:
-----------------------------------
Summary: table editor should use full canvas area available
Key: DROOLS-2155
URL: https://issues.jboss.org/browse/DROOLS-2155
Project: Drools
Issue Type: Bug
Components: DMN Editor
Reporter: Liz Clayton
Assignee: Michael Anstis
Priority: Minor
DMN table editor should use the full canvas width that is available (minus panels, toolbars, etc.) It should not appear as a smaller fixed size area, with scrollbars, within the canvas.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFBUILD-29) Add support for module version strings
by David Lloyd (JIRA)
David Lloyd created WFBUILD-29:
----------------------------------
Summary: Add support for module version strings
Key: WFBUILD-29
URL: https://issues.jboss.org/browse/WFBUILD-29
Project: WildFly Build Tools
Issue Type: Enhancement
Reporter: David Lloyd
Assignee: David Lloyd
Fix For: 1.2.3.Final
JBoss Modules supports version strings now. Allow version numbers to derive from artifacts or be hard-coded in the source {{module.xml}}.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years