4:22 a.m.
Hi all,
Is there a unit inside HAL code base I could use to automate checking that
the console is working properly after firing Wildfly? I've try to look for
that myself, but i've been a bit confused by the code base I'm must confess.
(I've kept it short, but feel free to ask for more context if you need to)
4:34 a.m.
You could try to use `curl --head http://localhost:9990/console/index.html`
<http://localhost:9990/console/index.html%60> which should return something like
HTTP/1.1 200 OK
Connection: keep-alive
Last-Modified: Fri, 13 Jul 2018 14:27:50 GMT
X-Frame-Options: SAMEORIGIN
Content-Length: 1288
Content-Type: text/html
Accept-Ranges: bytes
Date: Wed, 18 Jul 2018 08:33:37 GMT
On 18. Jul 2018, at 10:22, Romain Pelisse <belaran(a)redhat.com>
wrote:
Hi all,
Is there a unit inside HAL code base I could use to automate checking that the console is
working properly after firing Wildfly? I've try to look for that myself, but i've
been a bit confused by the code base I'm must confess.
(I've kept it short, but feel free to ask for more context if you need to)
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
4:42 a.m.
Darn, I knew I should have been a bit more verbose! :) I would like
something a bit more evolved. I'm no expert in HAL, but I've know webapps
to return 200 while being utterly broken. I was hoping to run a small
scenario, maybe something as stupid as trying to log in (even a failed
attempt, returning the proper code would be nice). Is there no way to run a
test from the suite standalone?
(I've try the usual mvn -Dtest without success, but I also need to
configure the testsuite to run against the proper instance)
If you think Curl is the better way to achieve that, I have no issue with
it. I assume we can also use it to interact with the ReST API, right?
Thanks!
On Wed, Jul 18, 2018 at 10:34 AM, Harald Pehl <hpehl(a)redhat.com> wrote:
You could try to use `curl --head http://localhost:9990/console/
index.html` which should return something like
HTTP/1.1 200 OK
Connection: keep-alive
Last-Modified: Fri, 13 Jul 2018 14:27:50 GMT
X-Frame-Options: SAMEORIGIN
Content-Length: 1288
Content-Type: text/html
Accept-Ranges: bytes
Date: Wed, 18 Jul 2018 08:33:37 GMT
On 18. Jul 2018, at 10:22, Romain Pelisse <belaran(a)redhat.com> wrote:
Hi all,
Is there a unit inside HAL code base I could use to automate checking that
the console is working properly after firing Wildfly? I've try to look for
that myself, but i've been a bit confused by the code base I'm must confess.
(I've kept it short, but feel free to ask for more context if you need to)
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12:41 p.m.
I'm unclear on the desired architecture.
You're asking for something in the HAL codebase itself, right? Not in
WildFly. But to test most scenarios, including authentication, you need to
have a running WildFly too, even though the HAL code you are testing is not
the code that WildFly serves. Is that an accurate summary?
On Wed, Jul 18, 2018 at 3:42 AM, Romain Pelisse <belaran(a)redhat.com> wrote:
Darn, I knew I should have been a bit more verbose! :) I would like
something a bit more evolved. I'm no expert in HAL, but I've know webapps
to return 200 while being utterly broken. I was hoping to run a small
scenario, maybe something as stupid as trying to log in (even a failed
attempt, returning the proper code would be nice). Is there no way to run a
test from the suite standalone?
(I've try the usual mvn -Dtest without success, but I also need to
configure the testsuite to run against the proper instance)
If you think Curl is the better way to achieve that, I have no issue with
it. I assume we can also use it to interact with the ReST API, right?
Thanks!
On Wed, Jul 18, 2018 at 10:34 AM, Harald Pehl <hpehl(a)redhat.com> wrote:
> You could try to use `curl --head http://localhost:9990/console/
> index.html` which should return something like
>
> HTTP/1.1 200 OK
> Connection: keep-alive
> Last-Modified: Fri, 13 Jul 2018 14:27:50 GMT
> X-Frame-Options: SAMEORIGIN
> Content-Length: 1288
> Content-Type: text/html
> Accept-Ranges: bytes
> Date: Wed, 18 Jul 2018 08:33:37 GMT
>
>
> On 18. Jul 2018, at 10:22, Romain Pelisse <belaran(a)redhat.com> wrote:
>
> Hi all,
>
> Is there a unit inside HAL code base I could use to automate checking
> that the console is working properly after firing Wildfly? I've try to look
> for that myself, but i've been a bit confused by the code base I'm must
> confess.
>
> (I've kept it short, but feel free to ask for more context if you need to)
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
2:03 p.m.
On Wed, Jul 18, 2018 at 5:42 AM, Romain Pelisse <belaran(a)redhat.com> wrote:
If you think Curl is the better way to achieve that, I have no issue with
it. I assume we can also use it to interact with the ReST API, right?
You can use curl to call operations or read resources, directly to the
management interface.
curl --digest -u admin:admin123@ -L -D -
http://localhost:9990/management --header "Content-Type:
application/json" -d
'{"operation":"test-connection-in-pool","address":[{"subsystem:
"datasources"},{"data-source":"ExampleDS"}]}'
curl --digest -u admin:admin123@ -L
'http://localhost:9990/management/deployment/kitchensink.war?operation=resource&include-runtime=true'
But if you want to test HAL itself, you can't do that with curl,
because HAL relies on several javascript libraries that curl doesn't
support (premises, fetch, etc.), there is also the CORS of the curl
client host to wildfly management interface.
--
Claudio Miranda
claudio(a)claudius.com.br
http://www.claudius.com.br
2106
days inactive
2106
days old
4 comments
4 participants
participants (4)
-
Brian Stansberry -
Claudio Miranda -
Harald Pehl -
Romain Pelisse