[JBoss JIRA] (WFLY-9893) Add integration test for wsprovide and wsconsume
by R Searls (JIRA)
[ https://issues.jboss.org/browse/WFLY-9893?page=com.atlassian.jira.plugin.... ]
R Searls commented on WFLY-9893:
--------------------------------
Withdrawing PR: https://github.com/wildfly/wildfly/pull/10931.
wsconsume.sh will not run successfully because there is an issue with jdk-9
and org.apache.cxf.tools.common.ClassUtils.compile. This should get resolved
by apache sometime in the future.
wsprovide.sh does not run because TeamCity env cannot resolve reference ...
Caused by: org.jboss.modules.xml.XmlPullParserException: Failed to resolve
artifact 'xalan:serializer:2.7.1.jbossorg-4' (position: END_TAG seen ...rces>\n
<artifact name="xalan:serializer:2.7.1.jbossorg-4"/>... @26:61)
However it runs successfully on my local machine (fedora).
May attempt to resubmit tests in some future release.
> Add integration test for wsprovide and wsconsume
> ------------------------------------------------
>
> Key: WFLY-9893
> URL: https://issues.jboss.org/browse/WFLY-9893
> Project: WildFly
> Issue Type: Task
> Components: Test Suite
> Affects Versions: 13.0.0.Beta1
> Reporter: R Searls
> Assignee: R Searls
> Priority: Minor
>
> Provide integration tests for wsprovide and wsconsume scripts.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 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-10
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] Latest draft: https://tools.ietf.org/html/draft-ietf-acme-acme-09
> 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: Farah Juma
>
> 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-10
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-1725) Update The WildFly High Availability Guide
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-1725?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-1725:
---------------------------------
Description:
The main source of clustering-related documentation for a Wildfly user is the High Availability Guide in the Wildfly documentation on docs.jboss.org.
Update this document into a quality document which will aid the user's understanding of new features and configuration in WildFly clustering.
was:
The main source of clustering-related documentation for a Wildfly user is the High Availability Guide in the Wildfly 8 documentation on docs.jboss.org.
Update this document into a quality document which will aid the user's understanding of new features and configuration in Wildfly 8 clustering.
https://docs.jboss.org/author/display/WFLY8/High+Availability+Guide
> Update The WildFly High Availability Guide
> -------------------------------------------
>
> Key: WFLY-1725
> URL: https://issues.jboss.org/browse/WFLY-1725
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.0.0.Alpha3
> Reporter: Richard Achmatowicz
> Assignee: Radoslav Husar
>
> The main source of clustering-related documentation for a Wildfly user is the High Availability Guide in the Wildfly documentation on docs.jboss.org.
> Update this document into a quality document which will aid the user's understanding of new features and configuration in WildFly clustering.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3667) Wildfly 12 : jboss-cli.sh in infinite loop
by Gaétan QUENTIN (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3667?page=com.atlassian.jira.plugi... ]
Gaétan QUENTIN updated WFCORE-3667:
-----------------------------------
Description:
i cannot use anymore the jboss-cli.sh to connect to the contoller since i migrated from v11 to 12:
wildfly@java2:/opt/Wildfly$ ls -la
drwxr-xr-x 1 root root 156 Mar 3 20:36 jboss-server-migration
drwxr-xr-x 1 root root 454 Mar 4 00:09 overlays
drwxr-xr-x 1 root root 166 Mar 4 11:43 scripts
drwxr-xr-x 1 root root 236 Oct 24 05:30 wildfly-11.0.0.Final
drwxr-xr-x 1 root root 236 Mar 1 07:29 wildfly-12.0.0.Final
lrwxrwxrwx 1 root root 20 Mar 4 12:49 wildfly-current -> wildfly-12.0.0.Final
my wildfly management console is on 172.20.12.192.
v12 has been migrated from v11 with the jboss-server-migration tool. Applications and app manager works fine and the wildfly instance controller is well binded on the requested ip.
with wildfly-current link on -> wildfly-11.0.0.Final:
this works perfectly:
(cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
with wildfly-current -> wildfly-12.0.0.Final:
this go in infinite loop until crash :
(cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
output:
'[standalone@172.20.12.192:9990' is not a valid operation name.
[standalone@172.20.12.192:9990 /] '[standalone@172.20.12.192:9990' is not a valid operation name.
''[standalone@172.20.12.192:9990'' is not a valid operation name.
[standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid operation name.
'[standalone@172.20.12.192:9990' is not a valid operation name.
[standalone@172.20.12.192:9990 /] '''[standalone@172.20.12.192:9990''' is not a valid operation name.
''''[standalone@172.20.12.192:9990'''' is not a valid operation name.
[standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid oper is not a valid operation name.
'[standalone@172.20.12.192:9990' is not a valid operation name.
[standalone@172.20.12.192:9990 /] '''''[standalone@172.20.12.192:9990''''' is not a valid operation name.
''''''[standalone@172.20.12.192:9990'''''' is not a valid operation name.
attached is a strace capture file (one of thousands) of jboss-cli .
was:
i cannot use anymore the jboss-cli.sh to connect to the contoller since i migrated from v11 to with wildfly 12:
wildfly@java2:/opt/Wildfly$ ls -la
drwxr-xr-x 1 root root 156 Mar 3 20:36 jboss-server-migration
drwxr-xr-x 1 root root 454 Mar 4 00:09 overlays
drwxr-xr-x 1 root root 166 Mar 4 11:43 scripts
drwxr-xr-x 1 root root 236 Oct 24 05:30 wildfly-11.0.0.Final
drwxr-xr-x 1 root root 236 Mar 1 07:29 wildfly-12.0.0.Final
lrwxrwxrwx 1 root root 20 Mar 4 12:49 wildfly-current -> wildfly-12.0.0.Final
my wildfly management console is on 172.20.12.192.
v12 has been migrated from v11 with the jboss-server-migration tool. Applications and app manager works fine and the wildfly instance controller is well binded on the requested ip.
with wildfly-current link on -> wildfly-11.0.0.Final:
this works perfectly:
(cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
with wildfly-current -> wildfly-12.0.0.Final:
this go in infinite loop until crash :
(cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
output:
'[standalone@172.20.12.192:9990' is not a valid operation name.
[standalone@172.20.12.192:9990 /] '[standalone@172.20.12.192:9990' is not a valid operation name.
''[standalone@172.20.12.192:9990'' is not a valid operation name.
[standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid operation name.
'[standalone@172.20.12.192:9990' is not a valid operation name.
[standalone@172.20.12.192:9990 /] '''[standalone@172.20.12.192:9990''' is not a valid operation name.
''''[standalone@172.20.12.192:9990'''' is not a valid operation name.
[standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid oper is not a valid operation name.
'[standalone@172.20.12.192:9990' is not a valid operation name.
[standalone@172.20.12.192:9990 /] '''''[standalone@172.20.12.192:9990''''' is not a valid operation name.
''''''[standalone@172.20.12.192:9990'''''' is not a valid operation name.
attached is a strace capture file (one of thousands) of jboss-cli .
> Wildfly 12 : jboss-cli.sh in infinite loop
> -------------------------------------------
>
> Key: WFCORE-3667
> URL: https://issues.jboss.org/browse/WFCORE-3667
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Environment: ubuntu 16.06 lxd container
> java version "1.8.0_161" oracle
> v12 migrated from v11
> Reporter: Gaétan QUENTIN
> Assignee: Jean-Francois Denise
> Priority: Critical
> Labels: regression
> Attachments: aesh-readline-1.5.jar, jboss-cli-logging.properties, jboss-cli.25300, jboss-cli.log, term.txt
>
>
> i cannot use anymore the jboss-cli.sh to connect to the contoller since i migrated from v11 to 12:
>
> wildfly@java2:/opt/Wildfly$ ls -la
> drwxr-xr-x 1 root root 156 Mar 3 20:36 jboss-server-migration
> drwxr-xr-x 1 root root 454 Mar 4 00:09 overlays
> drwxr-xr-x 1 root root 166 Mar 4 11:43 scripts
> drwxr-xr-x 1 root root 236 Oct 24 05:30 wildfly-11.0.0.Final
> drwxr-xr-x 1 root root 236 Mar 1 07:29 wildfly-12.0.0.Final
> lrwxrwxrwx 1 root root 20 Mar 4 12:49 wildfly-current -> wildfly-12.0.0.Final
>
>
> my wildfly management console is on 172.20.12.192.
> v12 has been migrated from v11 with the jboss-server-migration tool. Applications and app manager works fine and the wildfly instance controller is well binded on the requested ip.
>
>
> with wildfly-current link on -> wildfly-11.0.0.Final:
>
> this works perfectly:
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
>
> with wildfly-current -> wildfly-12.0.0.Final:
> this go in infinite loop until crash :
> (cd /opt/Wildfly/wildfly-current/bin && ./jboss-cli.sh -c -u=xx -p=xx --controller=http-remoting://172.20.12.192:9990)
>
> output:
>
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '[standalone@172.20.12.192:9990' is not a valid operation name.
> ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''[standalone@172.20.12.192:9990''' is not a valid operation name.
> ''''[standalone@172.20.12.192:9990'''' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] [standalone@172.20.12.192:9990 /] ''[standalone@172.20.12.192:9990'' is not a valid oper is not a valid operation name.
> '[standalone@172.20.12.192:9990' is not a valid operation name.
> [standalone@172.20.12.192:9990 /] '''''[standalone@172.20.12.192:9990''''' is not a valid operation name.
> ''''''[standalone@172.20.12.192:9990'''''' is not a valid operation name.
> attached is a strace capture file (one of thousands) of jboss-cli .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3674) Cannot connect to JBoss controller via CLI by passing password in command line if password contains '!' character (for JBoss EAP 7.1.0.GA in Windows)
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3674?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise moved JBEAP-14339 to WFCORE-3674:
------------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-3674 (was: JBEAP-14339)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
Affects Version/s: (was: 7.1.0.GA)
> Cannot connect to JBoss controller via CLI by passing password in command line if password contains '!' character (for JBoss EAP 7.1.0.GA in Windows)
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3674
> URL: https://issues.jboss.org/browse/WFCORE-3674
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> For JBoss EAP 7.1.0.GA in Windows (e.g. Microsoft Windows Server 2016):
> Cannot connect to JBoss controller via CLI by passing password in command line if password contains '!' character. Wrapping password by double quotes does not help.
> For example:
> {code}
> jboss-cli.bat -c controller=localhost --user=myuser --password=mypass1!
> Failed to connect to the controller: Unable to authenticate against controller at localhost:9990: Authentication failed: all available authentication mechanisms failed:
> DIGEST-MD5: javax.security.sasl.SaslException: DIGEST-MD5: Server rejected authentication
> Press any key to continue . . .
> {code}
> In the same time it is possible to connect with such password when cli prompts for it or via management console.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9974) Remove unused 'basic-authType' complex type in wildfly-undertow xsd file
by Jan Stourac (JIRA)
Jan Stourac created WFLY-9974:
---------------------------------
Summary: Remove unused 'basic-authType' complex type in wildfly-undertow xsd file
Key: WFLY-9974
URL: https://issues.jboss.org/browse/WFLY-9974
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 12.0.0.Final
Reporter: Jan Stourac
Assignee: Stuart Douglas
Priority: Minor
Since undertow subsystem version 4.0, the [{{basic-authType}}|https://github.com/wildfly/wildfly/blob/master/undertow/src/main/resources/schema/wildfly-undertow_5_0.xsd#L578-L580] has not been utilized anymore. We should probably remove that type definition from our xsd file with another subsystem version bump.
This type was used for {{basic-auth}} filter which is no longer present in undertow.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months