[JBoss JIRA] (WFCORE-3437) CLI can't be started on Solaris
by Marek Kopecký (JIRA)
Marek Kopecký created WFCORE-3437:
-------------------------------------
Summary: CLI can't be started on Solaris
Key: WFCORE-3437
URL: https://issues.jboss.org/browse/WFCORE-3437
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Marek Kopecký
Assignee: Jean-Francois Denise
Priority: Critical
CLI (WildFly master) can't be started on Solaris:
{noformat}
[hudson@dev34-02 bin]$ ./jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
java.io.IOException: Error executing 'stty size': unknown mode: size
: Error executing 'stty size': unknown mode: size
[hudson@dev34-02 bin]$
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFLY-8948) SAML2STSLoginModule cannot be configured with module options instead of configFile
by Vladimir Dosoudil (JIRA)
[ https://issues.jboss.org/browse/WFLY-8948?page=com.atlassian.jira.plugin.... ]
Vladimir Dosoudil updated WFLY-8948:
------------------------------------
Labels: downstream_dependency (was: )
> SAML2STSLoginModule cannot be configured with module options instead of configFile
> ----------------------------------------------------------------------------------
>
> Key: WFLY-8948
> URL: https://issues.jboss.org/browse/WFLY-8948
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Security
> Reporter: Jiri Ondrusek
> Assignee: Jiri Ondrusek
> Labels: downstream_dependency
>
> It is not possible to configure the SAML2STSLoginModule by using module options instead of configFile:
> <security-domain name="sts" cache-type="default">
> <authentication>
> <login-module code="org.picketlink.identity.federation.bindings.jboss.auth.SAML2STSLoginModule" flag="required" module="org.picketlink">
> <module-option name="serviceName" value="PicketLinkSTS"/>
> <module-option name="portName" value="PicketLinkSTSPort"/>
> <module-option name="endpointAddress" value="http://localhost:8080/picketlink-sts/PicketLinkSTS"/>
> <module-option name="username" value="admin"/>
> <module-option name="password" value="admin"/>
> See BZ for more information.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3435) Expose capability/requirements to deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3435?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-3435:
----------------------------------------
Assignee: (was: Jason Greene)
> Expose capability/requirements to deployments
> ---------------------------------------------
>
> Key: WFCORE-3435
> URL: https://issues.jboss.org/browse/WFCORE-3435
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 3.0.9.Final
> Reporter: Bob McWhirter
>
> For WildFly Swarm, we use a fair amount of ServiceActivators in deployments.
> Moving to WF11, we have seen some of our dependencies on Service<T>, such as NamingService.SERVICE_NAME result in deprecation warnings suggesting we move to using CAPABILITY_NAME. From within a ServiceActivator, within a deployment, this appears to not be a possibility.
> Filed per [~ctomc]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3435) Expose capability/requirements to deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3435?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3435:
-------------------------------------
Component/s: Domain Management
> Expose capability/requirements to deployments
> ---------------------------------------------
>
> Key: WFCORE-3435
> URL: https://issues.jboss.org/browse/WFCORE-3435
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Affects Versions: 3.0.9.Final
> Reporter: Bob McWhirter
> Assignee: Jason Greene
>
> For WildFly Swarm, we use a fair amount of ServiceActivators in deployments.
> Moving to WF11, we have seen some of our dependencies on Service<T>, such as NamingService.SERVICE_NAME result in deprecation warnings suggesting we move to using CAPABILITY_NAME. From within a ServiceActivator, within a deployment, this appears to not be a possibility.
> Filed per [~ctomc]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 7 months
[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, 7 months
[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, 7 months
[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, 7 months
[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, 7 months
[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, 7 months