From arun.gupta at gmail.com  Tue Sep  1 13:20:20 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 1 Sep 2015 10:20:20 -0700
Subject: [wildfly-dev] WildFly Server IP Address and Port
Message-ID: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>

Assuming WildFly is bound to all available IP addresses using -b
0.0.0.0, is there a WildFly-specific API that can be used to obtain
the IP address where the server is running?

Ideally, I'd like something like:

WildFly.getHostAddress()
WildFly.getHostPort()

It could be running in a Docker container, in AWS, on my local laptop,
in OpenShift, or any where else and would like the IP address to be
returned correctly.

Suggestions?

Arun

-- 
http://blog.arungupta.me
http://twitter.com/arungupta

From filippespolti at gmail.com  Tue Sep  1 13:25:13 2015
From: filippespolti at gmail.com (Filippe spolti)
Date: Tue, 1 Sep 2015 14:25:13 -0300
Subject: [wildfly-dev] WildFly Server IP Address and Port
In-Reply-To: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>
References: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>
Message-ID: <55E5DF79.7090207@gmail.com>

Hello Arun,

I usethis code w/ Jboss 7 and wildfly 8, i didn't test with wildfly 9/10.

         MBeanServer mBeanServer = 
ManagementFactory.getPlatformMBeanServer();
         String url = null;
         try {

             ObjectName http = new 
ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=http");
             String jbossHttpAddress = (String) 
mBeanServer.getAttribute(http,"boundAddress");
             int jbossHttpPort = (Integer) 
mBeanServer.getAttribute(http,"boundPort");
             url = jbossHttpAddress + ":" + jbossHttpPort;
             log.fine("Url obtained from the system: " + url);
         } catch (Exception e) {
             log.severe(e.getStackTrace().toString());
         }
         return url;

regards.


On 09/01/2015 02:20 PM, Arun Gupta wrote:
> Assuming WildFly is bound to all available IP addresses using -b
> 0.0.0.0, is there a WildFly-specific API that can be used to obtain
> the IP address where the server is running?
>
> Ideally, I'd like something like:
>
> WildFly.getHostAddress()
> WildFly.getHostPort()
>
> It could be running in a Docker container, in AWS, on my local laptop,
> in OpenShift, or any where else and would like the IP address to be
> returned correctly.
>
> Suggestions?
>
> Arun
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150901/a74bcf24/attachment-0001.html 

From bmcwhirt at redhat.com  Tue Sep  1 13:38:56 2015
From: bmcwhirt at redhat.com (Bob McWhirter)
Date: Tue, 1 Sep 2015 14:38:56 -0300
Subject: [wildfly-dev] WildFly Server IP Address and Port
In-Reply-To: <55E5DF79.7090207@gmail.com>
References: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>
	<55E5DF79.7090207@gmail.com>
Message-ID: <CA+45JvGS2N=T6vKjtmixVicLsvLEc4E6HPtV92gj3wGds=03Lg@mail.gmail.com>

Is this something JGroups/Clustering could use?  I've found that using
0.0.0.0 makes JGroups complain, because it has no idea which interface to
actually use for multicast.


On Tue, Sep 1, 2015 at 2:25 PM, Filippe spolti <filippespolti at gmail.com>
wrote:

> Hello Arun,
>
> I usethis code w/ Jboss 7 and wildfly 8, i didn't test with wildfly 9/10.
>
>         MBeanServer mBeanServer =
> ManagementFactory.getPlatformMBeanServer();
>         String url = null;
>         try {
>
>             ObjectName http = new ObjectName("jboss.as:
> socket-binding-group=standard-sockets,socket-binding=http");
>             String jbossHttpAddress = (String)
> mBeanServer.getAttribute(http,"boundAddress");
>             int jbossHttpPort = (Integer)
> mBeanServer.getAttribute(http,"boundPort");
>             url = jbossHttpAddress + ":" + jbossHttpPort;
>             log.fine("Url obtained from the system: " + url);
>         } catch (Exception e) {
>             log.severe(e.getStackTrace().toString());
>         }
>         return url;
>
> regards.
>
>
> On 09/01/2015 02:20 PM, Arun Gupta wrote:
>
> Assuming WildFly is bound to all available IP addresses using -b
> 0.0.0.0, is there a WildFly-specific API that can be used to obtain
> the IP address where the server is running?
>
> Ideally, I'd like something like:
>
> WildFly.getHostAddress()
> WildFly.getHostPort()
>
> It could be running in a Docker container, in AWS, on my local laptop,
> in OpenShift, or any where else and would like the IP address to be
> returned correctly.
>
> Suggestions?
>
> Arun
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150901/ee4a1ac9/attachment.html 

From ttarrant at redhat.com  Tue Sep  1 15:40:16 2015
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Tue, 1 Sep 2015 15:40:16 -0400 (EDT)
Subject: [wildfly-dev] WildFly Server IP Address and Port
In-Reply-To: <CA+45JvGS2N=T6vKjtmixVicLsvLEc4E6HPtV92gj3wGds=03Lg@mail.gmail.com>
References: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>
	<55E5DF79.7090207@gmail.com>
	<CA+45JvGS2N=T6vKjtmixVicLsvLEc4E6HPtV92gj3wGds=03Lg@mail.gmail.com>
Message-ID: <1060e89a-b559-43a8-9bc4-00bd1a947313@redhat.com>

You are getting the address of the public http interface which might not necessarily correspond to the port you want to use for clustering.?

--
Tristan Tarrant?
Infinispan Lead?
JBoss a division of Red Hat?

From: Bob McWhirter
Sent: 1 Sep 2015 19:39
To: Filippe spolti
Cc: wildfly-dev at lists.jboss.org
Subject: Re: [wildfly-dev] WildFly Server IP Address and Port

Is this something JGroups/Clustering could use?  I've found that using
0.0.0.0 makes JGroups complain, because it has no idea which interface to
actually use for multicast.


On Tue, Sep 1, 2015 at 2:25 PM, Filippe spolti <filippespolti at gmail.com>
wrote:

> Hello Arun,
>
> I usethis code w/ Jboss 7 and wildfly 8, i didn't test with wildfly 9/10.
>
>         MBeanServer mBeanServer =
> ManagementFactory.getPlatformMBeanServer();
>         String url = null;
>         try {
>
>             ObjectName http = new ObjectName("jboss.as:
> socket-binding-group=standard-sockets,socket-binding=http");
>             String jbossHttpAddress = (String)
> mBeanServer.getAttribute(http,"boundAddress");
>             int jbossHttpPort = (Integer)
> mBeanServer.getAttribute(http,"boundPort");
>             url = jbossHttpAddress + ":" + jbossHttpPort;
>             log.fine("Url obtained from the system: " + url);
>         } catch (Exception e) {
>             log.severe(e.getStackTrace().toString());
>         }
>         return url;
>
> regards.
>
>
> On 09/01/2015 02:20 PM, Arun Gupta wrote:
>
> Assuming WildFly is bound to all available IP addresses using -b
> 0.0.0.0, is there a WildFly-specific API that can be used to obtain
> the IP address where the server is running?
>
> Ideally, I'd like something like:
>
> WildFly.getHostAddress()
> WildFly.getHostPort()
>
> It could be running in a Docker container, in AWS, on my local laptop,
> in OpenShift, or any where else and would like the IP address to be
> returned correctly.
>
> Suggestions?
>
> Arun
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150901/ab8169f9/attachment.html 
-------------- next part --------------
_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

From brian.stansberry at redhat.com  Tue Sep  1 16:31:41 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 1 Sep 2015 15:31:41 -0500
Subject: [wildfly-dev] WildFly Server IP Address and Port
In-Reply-To: <55E5DF79.7090207@gmail.com>
References: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>
	<55E5DF79.7090207@gmail.com>
Message-ID: <55E60B2D.5040407@redhat.com>

That JMX operation (or the CLI equivalent[1]) will return 0.0.0.0 which 
really is the bound address but AIUI isn't what's wanted.

If the server is configured to use 0.0.0.0, there is no single 
"WildFly.getHostAddress()". That setting means the relevant sockets will 
be listening on all available interfaces on the machine. Which of those 
is the one that's useful to a particular client depends on the network 
topology.

BTW, if you know the names of the nics in your target environment but 
don't know the addresses, WildFly (and EAP) let you configure the 
interfaces to use a particular nic. If binding to 0.0.0.0 is a 
workaround for not knowing the actual addresses, that may help. For example:

<interface name="public">
    <nic name="eth0"/>
</interface>

The 'name' attribute also allows expressions:

<nic name="${my.public.nic:eth0}"/>

With that kind of config, the JMX query Filippe showed will provide a 
regular address.

[1] The CLI op:

[standalone at localhost:9990 /] 
/socket-binding-group=standard-sockets/socket-binding=http:read-attribute(name=bound-address)
{
     "outcome" => "success",
     "result" => "0.0.0.0"
}

On 9/1/15 12:25 PM, Filippe spolti wrote:
> Hello Arun,
>
> I usethis code w/ Jboss 7 and wildfly 8, i didn't test with wildfly 9/10.
>
>          MBeanServer mBeanServer =
> ManagementFactory.getPlatformMBeanServer();
>          String url = null;
>          try {
>
>              ObjectName http = new
> ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=http");
>              String jbossHttpAddress = (String)
> mBeanServer.getAttribute(http,"boundAddress");
>              int jbossHttpPort = (Integer)
> mBeanServer.getAttribute(http,"boundPort");
>              url = jbossHttpAddress + ":" + jbossHttpPort;
>              log.fine("Url obtained from the system: " + url);
>          } catch (Exception e) {
>              log.severe(e.getStackTrace().toString());
>          }
>          return url;
>
> regards.
>
>
> On 09/01/2015 02:20 PM, Arun Gupta wrote:
>> Assuming WildFly is bound to all available IP addresses using -b
>> 0.0.0.0, is there a WildFly-specific API that can be used to obtain
>> the IP address where the server is running?
>>
>> Ideally, I'd like something like:
>>
>> WildFly.getHostAddress()
>> WildFly.getHostPort()
>>
>> It could be running in a Docker container, in AWS, on my local laptop,
>> in OpenShift, or any where else and would like the IP address to be
>> returned correctly.
>>
>> Suggestions?
>>
>> Arun
>>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From arun.gupta at gmail.com  Tue Sep  1 17:34:14 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 1 Sep 2015 14:34:14 -0700
Subject: [wildfly-dev] WildFly Server IP Address and Port
In-Reply-To: <55E60B2D.5040407@redhat.com>
References: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>
	<55E5DF79.7090207@gmail.com> <55E60B2D.5040407@redhat.com>
Message-ID: <CAGBoHQXWhgmGgj=Y0NeNFJm3QfYLTk-Q=hyrwEaY5yzj0E6pMw@mail.gmail.com>

Brian,

How do you envision this working in a Docker environment?

If multiple WildFly containers are running on the same Docker Host
(which is going to be common use case), should each WildFly be bound
to the IP address of the host?

Possibly invoked with a different port offset?

Arun

On Tue, Sep 1, 2015 at 1:31 PM, Brian Stansberry
<brian.stansberry at redhat.com> wrote:
> That JMX operation (or the CLI equivalent[1]) will return 0.0.0.0 which
> really is the bound address but AIUI isn't what's wanted.
>
> If the server is configured to use 0.0.0.0, there is no single
> "WildFly.getHostAddress()". That setting means the relevant sockets will
> be listening on all available interfaces on the machine. Which of those
> is the one that's useful to a particular client depends on the network
> topology.
>
> BTW, if you know the names of the nics in your target environment but
> don't know the addresses, WildFly (and EAP) let you configure the
> interfaces to use a particular nic. If binding to 0.0.0.0 is a
> workaround for not knowing the actual addresses, that may help. For example:
>
> <interface name="public">
>     <nic name="eth0"/>
> </interface>
>
> The 'name' attribute also allows expressions:
>
> <nic name="${my.public.nic:eth0}"/>
>
> With that kind of config, the JMX query Filippe showed will provide a
> regular address.
>
> [1] The CLI op:
>
> [standalone at localhost:9990 /]
> /socket-binding-group=standard-sockets/socket-binding=http:read-attribute(name=bound-address)
> {
>      "outcome" => "success",
>      "result" => "0.0.0.0"
> }
>
> On 9/1/15 12:25 PM, Filippe spolti wrote:
>> Hello Arun,
>>
>> I usethis code w/ Jboss 7 and wildfly 8, i didn't test with wildfly 9/10.
>>
>>          MBeanServer mBeanServer =
>> ManagementFactory.getPlatformMBeanServer();
>>          String url = null;
>>          try {
>>
>>              ObjectName http = new
>> ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=http");
>>              String jbossHttpAddress = (String)
>> mBeanServer.getAttribute(http,"boundAddress");
>>              int jbossHttpPort = (Integer)
>> mBeanServer.getAttribute(http,"boundPort");
>>              url = jbossHttpAddress + ":" + jbossHttpPort;
>>              log.fine("Url obtained from the system: " + url);
>>          } catch (Exception e) {
>>              log.severe(e.getStackTrace().toString());
>>          }
>>          return url;
>>
>> regards.
>>
>>
>> On 09/01/2015 02:20 PM, Arun Gupta wrote:
>>> Assuming WildFly is bound to all available IP addresses using -b
>>> 0.0.0.0, is there a WildFly-specific API that can be used to obtain
>>> the IP address where the server is running?
>>>
>>> Ideally, I'd like something like:
>>>
>>> WildFly.getHostAddress()
>>> WildFly.getHostPort()
>>>
>>> It could be running in a Docker container, in AWS, on my local laptop,
>>> in OpenShift, or any where else and would like the IP address to be
>>> returned correctly.
>>>
>>> Suggestions?
>>>
>>> Arun
>>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
http://blog.arungupta.me
http://twitter.com/arungupta

From brian.stansberry at redhat.com  Tue Sep  1 18:33:58 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 1 Sep 2015 17:33:58 -0500
Subject: [wildfly-dev] WildFly Server IP Address and Port
In-Reply-To: <CAGBoHQXWhgmGgj=Y0NeNFJm3QfYLTk-Q=hyrwEaY5yzj0E6pMw@mail.gmail.com>
References: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>
	<55E5DF79.7090207@gmail.com> <55E60B2D.5040407@redhat.com>
	<CAGBoHQXWhgmGgj=Y0NeNFJm3QfYLTk-Q=hyrwEaY5yzj0E6pMw@mail.gmail.com>
Message-ID: <55E627D6.1050904@redhat.com>

Is this scenario different from running multiple WildFly instances on a 
single machine in a non-Docker setup?

If not, your choices are to associate each instance with a different 
address, or to use port offsets. If there's only one available address 
then you're down to port offsets.

On 9/1/15 4:34 PM, Arun Gupta wrote:
> Brian,
>
> How do you envision this working in a Docker environment?
>
> If multiple WildFly containers are running on the same Docker Host
> (which is going to be common use case), should each WildFly be bound
> to the IP address of the host?
>
> Possibly invoked with a different port offset?
>
> Arun
>
> On Tue, Sep 1, 2015 at 1:31 PM, Brian Stansberry
> <brian.stansberry at redhat.com> wrote:
>> That JMX operation (or the CLI equivalent[1]) will return 0.0.0.0 which
>> really is the bound address but AIUI isn't what's wanted.
>>
>> If the server is configured to use 0.0.0.0, there is no single
>> "WildFly.getHostAddress()". That setting means the relevant sockets will
>> be listening on all available interfaces on the machine. Which of those
>> is the one that's useful to a particular client depends on the network
>> topology.
>>
>> BTW, if you know the names of the nics in your target environment but
>> don't know the addresses, WildFly (and EAP) let you configure the
>> interfaces to use a particular nic. If binding to 0.0.0.0 is a
>> workaround for not knowing the actual addresses, that may help. For example:
>>
>> <interface name="public">
>>      <nic name="eth0"/>
>> </interface>
>>
>> The 'name' attribute also allows expressions:
>>
>> <nic name="${my.public.nic:eth0}"/>
>>
>> With that kind of config, the JMX query Filippe showed will provide a
>> regular address.
>>
>> [1] The CLI op:
>>
>> [standalone at localhost:9990 /]
>> /socket-binding-group=standard-sockets/socket-binding=http:read-attribute(name=bound-address)
>> {
>>       "outcome" => "success",
>>       "result" => "0.0.0.0"
>> }
>>
>> On 9/1/15 12:25 PM, Filippe spolti wrote:
>>> Hello Arun,
>>>
>>> I usethis code w/ Jboss 7 and wildfly 8, i didn't test with wildfly 9/10.
>>>
>>>           MBeanServer mBeanServer =
>>> ManagementFactory.getPlatformMBeanServer();
>>>           String url = null;
>>>           try {
>>>
>>>               ObjectName http = new
>>> ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=http");
>>>               String jbossHttpAddress = (String)
>>> mBeanServer.getAttribute(http,"boundAddress");
>>>               int jbossHttpPort = (Integer)
>>> mBeanServer.getAttribute(http,"boundPort");
>>>               url = jbossHttpAddress + ":" + jbossHttpPort;
>>>               log.fine("Url obtained from the system: " + url);
>>>           } catch (Exception e) {
>>>               log.severe(e.getStackTrace().toString());
>>>           }
>>>           return url;
>>>
>>> regards.
>>>
>>>
>>> On 09/01/2015 02:20 PM, Arun Gupta wrote:
>>>> Assuming WildFly is bound to all available IP addresses using -b
>>>> 0.0.0.0, is there a WildFly-specific API that can be used to obtain
>>>> the IP address where the server is running?
>>>>
>>>> Ideally, I'd like something like:
>>>>
>>>> WildFly.getHostAddress()
>>>> WildFly.getHostPort()
>>>>
>>>> It could be running in a Docker container, in AWS, on my local laptop,
>>>> in OpenShift, or any where else and would like the IP address to be
>>>> returned correctly.
>>>>
>>>> Suggestions?
>>>>
>>>> Arun
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From arun.gupta at gmail.com  Tue Sep  1 18:47:35 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 1 Sep 2015 15:47:35 -0700
Subject: [wildfly-dev] WildFly Server IP Address and Port
In-Reply-To: <55E627D6.1050904@redhat.com>
References: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>
	<55E5DF79.7090207@gmail.com> <55E60B2D.5040407@redhat.com>
	<CAGBoHQXWhgmGgj=Y0NeNFJm3QfYLTk-Q=hyrwEaY5yzj0E6pMw@mail.gmail.com>
	<55E627D6.1050904@redhat.com>
Message-ID: <CAGBoHQWUu169VE28860=3nf1peVnAUKqOxgVFP8zWN-M7zFBvQ@mail.gmail.com>

On Tue, Sep 1, 2015 at 3:33 PM, Brian Stansberry
<brian.stansberry at redhat.com> wrote:
> Is this scenario different from running multiple WildFly instances on a
> single machine in a non-Docker setup?

Good point, they are the same.

>
> If not, your choices are to associate each instance with a different
> address, or to use port offsets. If there's only one available address then
> you're down to port offsets.


So, if WildFly runs with -b <IP_ADDRESS> then the utility above will
give the correct address and port?

Arun

>
>
> On 9/1/15 4:34 PM, Arun Gupta wrote:
>>
>> Brian,
>>
>> How do you envision this working in a Docker environment?
>>
>> If multiple WildFly containers are running on the same Docker Host
>> (which is going to be common use case), should each WildFly be bound
>> to the IP address of the host?
>>
>> Possibly invoked with a different port offset?
>>
>> Arun
>>
>> On Tue, Sep 1, 2015 at 1:31 PM, Brian Stansberry
>> <brian.stansberry at redhat.com> wrote:
>>>
>>> That JMX operation (or the CLI equivalent[1]) will return 0.0.0.0 which
>>> really is the bound address but AIUI isn't what's wanted.
>>>
>>> If the server is configured to use 0.0.0.0, there is no single
>>> "WildFly.getHostAddress()". That setting means the relevant sockets will
>>> be listening on all available interfaces on the machine. Which of those
>>> is the one that's useful to a particular client depends on the network
>>> topology.
>>>
>>> BTW, if you know the names of the nics in your target environment but
>>> don't know the addresses, WildFly (and EAP) let you configure the
>>> interfaces to use a particular nic. If binding to 0.0.0.0 is a
>>> workaround for not knowing the actual addresses, that may help. For
>>> example:
>>>
>>> <interface name="public">
>>>      <nic name="eth0"/>
>>> </interface>
>>>
>>> The 'name' attribute also allows expressions:
>>>
>>> <nic name="${my.public.nic:eth0}"/>
>>>
>>> With that kind of config, the JMX query Filippe showed will provide a
>>> regular address.
>>>
>>> [1] The CLI op:
>>>
>>> [standalone at localhost:9990 /]
>>>
>>> /socket-binding-group=standard-sockets/socket-binding=http:read-attribute(name=bound-address)
>>> {
>>>       "outcome" => "success",
>>>       "result" => "0.0.0.0"
>>> }
>>>
>>> On 9/1/15 12:25 PM, Filippe spolti wrote:
>>>>
>>>> Hello Arun,
>>>>
>>>> I usethis code w/ Jboss 7 and wildfly 8, i didn't test with wildfly
>>>> 9/10.
>>>>
>>>>           MBeanServer mBeanServer =
>>>> ManagementFactory.getPlatformMBeanServer();
>>>>           String url = null;
>>>>           try {
>>>>
>>>>               ObjectName http = new
>>>>
>>>> ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=http");
>>>>               String jbossHttpAddress = (String)
>>>> mBeanServer.getAttribute(http,"boundAddress");
>>>>               int jbossHttpPort = (Integer)
>>>> mBeanServer.getAttribute(http,"boundPort");
>>>>               url = jbossHttpAddress + ":" + jbossHttpPort;
>>>>               log.fine("Url obtained from the system: " + url);
>>>>           } catch (Exception e) {
>>>>               log.severe(e.getStackTrace().toString());
>>>>           }
>>>>           return url;
>>>>
>>>> regards.
>>>>
>>>>
>>>> On 09/01/2015 02:20 PM, Arun Gupta wrote:
>>>>>
>>>>> Assuming WildFly is bound to all available IP addresses using -b
>>>>> 0.0.0.0, is there a WildFly-specific API that can be used to obtain
>>>>> the IP address where the server is running?
>>>>>
>>>>> Ideally, I'd like something like:
>>>>>
>>>>> WildFly.getHostAddress()
>>>>> WildFly.getHostPort()
>>>>>
>>>>> It could be running in a Docker container, in AWS, on my local laptop,
>>>>> in OpenShift, or any where else and would like the IP address to be
>>>>> returned correctly.
>>>>>
>>>>> Suggestions?
>>>>>
>>>>> Arun
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Senior Principal Software Engineer
>>> JBoss by Red Hat
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat



-- 
http://blog.arungupta.me
http://twitter.com/arungupta

From arun.gupta at gmail.com  Tue Sep  1 18:51:30 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 1 Sep 2015 15:51:30 -0700
Subject: [wildfly-dev] WildFly Server IP Address and Port
In-Reply-To: <55E5DF79.7090207@gmail.com>
References: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>
	<55E5DF79.7090207@gmail.com>
Message-ID: <CAGBoHQUq821O=YPV=eAPL1wc-2uv4U8wGaqE9SWBgR9uXvwP+w@mail.gmail.com>

Filippe,

Somebody coded the utility as shown at:

https://github.com/arun-gupta/microservices/blob/master/microservice/utils/src/main/java/org/javaee7/wildfly/samples/everest/utils/WildflyUtil.java#L46

But I guess yours is the correct way. WDYT?

Arun

On Tue, Sep 1, 2015 at 10:25 AM, Filippe spolti <filippespolti at gmail.com> wrote:
> Hello Arun,
>
> I usethis code w/ Jboss 7 and wildfly 8, i didn't test with wildfly 9/10.
>
>         MBeanServer mBeanServer =
> ManagementFactory.getPlatformMBeanServer();
>         String url = null;
>         try {
>
>             ObjectName http = new
> ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=http");
>             String jbossHttpAddress = (String)
> mBeanServer.getAttribute(http,"boundAddress");
>             int jbossHttpPort = (Integer)
> mBeanServer.getAttribute(http,"boundPort");
>             url = jbossHttpAddress + ":" + jbossHttpPort;
>             log.fine("Url obtained from the system: " + url);
>         } catch (Exception e) {
>             log.severe(e.getStackTrace().toString());
>         }
>         return url;
>
> regards.
>
>
> On 09/01/2015 02:20 PM, Arun Gupta wrote:
>
> Assuming WildFly is bound to all available IP addresses using -b
> 0.0.0.0, is there a WildFly-specific API that can be used to obtain
> the IP address where the server is running?
>
> Ideally, I'd like something like:
>
> WildFly.getHostAddress()
> WildFly.getHostPort()
>
> It could be running in a Docker container, in AWS, on my local laptop,
> in OpenShift, or any where else and would like the IP address to be
> returned correctly.
>
> Suggestions?
>
> Arun
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
http://blog.arungupta.me
http://twitter.com/arungupta

From brian.stansberry at redhat.com  Tue Sep  1 19:06:36 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 1 Sep 2015 18:06:36 -0500
Subject: [wildfly-dev] WildFly Server IP Address and Port
In-Reply-To: <CAGBoHQWUu169VE28860=3nf1peVnAUKqOxgVFP8zWN-M7zFBvQ@mail.gmail.com>
References: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>
	<55E5DF79.7090207@gmail.com> <55E60B2D.5040407@redhat.com>
	<CAGBoHQXWhgmGgj=Y0NeNFJm3QfYLTk-Q=hyrwEaY5yzj0E6pMw@mail.gmail.com>
	<55E627D6.1050904@redhat.com>
	<CAGBoHQWUu169VE28860=3nf1peVnAUKqOxgVFP8zWN-M7zFBvQ@mail.gmail.com>
Message-ID: <55E62F7C.8070204@redhat.com>

On 9/1/15 5:47 PM, Arun Gupta wrote:
> On Tue, Sep 1, 2015 at 3:33 PM, Brian Stansberry
> <brian.stansberry at redhat.com> wrote:
>> Is this scenario different from running multiple WildFly instances on a
>> single machine in a non-Docker setup?
>
> Good point, they are the same.
>

Reading a bit more, it seems Docker gives each container its own 
address, visible to the container via the eth0 interface:

https://docs.docker.com/articles/networking/

>>
>> If not, your choices are to associate each instance with a different
>> address, or to use port offsets. If there's only one available address then
>> you're down to port offsets.
>
>
> So, if WildFly runs with -b <IP_ADDRESS> then the utility above will
> give the correct address and port?
>

Yes, assuming IP_ADDRESS != 0.0.0.0, the server config is using a 
socket-binding named "http" for the web server, and the web server 
address/port is the one you want.

> Arun
>
>>
>>
>> On 9/1/15 4:34 PM, Arun Gupta wrote:
>>>
>>> Brian,
>>>
>>> How do you envision this working in a Docker environment?
>>>
>>> If multiple WildFly containers are running on the same Docker Host
>>> (which is going to be common use case), should each WildFly be bound
>>> to the IP address of the host?
>>>
>>> Possibly invoked with a different port offset?
>>>
>>> Arun
>>>
>>> On Tue, Sep 1, 2015 at 1:31 PM, Brian Stansberry
>>> <brian.stansberry at redhat.com> wrote:
>>>>
>>>> That JMX operation (or the CLI equivalent[1]) will return 0.0.0.0 which
>>>> really is the bound address but AIUI isn't what's wanted.
>>>>
>>>> If the server is configured to use 0.0.0.0, there is no single
>>>> "WildFly.getHostAddress()". That setting means the relevant sockets will
>>>> be listening on all available interfaces on the machine. Which of those
>>>> is the one that's useful to a particular client depends on the network
>>>> topology.
>>>>
>>>> BTW, if you know the names of the nics in your target environment but
>>>> don't know the addresses, WildFly (and EAP) let you configure the
>>>> interfaces to use a particular nic. If binding to 0.0.0.0 is a
>>>> workaround for not knowing the actual addresses, that may help. For
>>>> example:
>>>>
>>>> <interface name="public">
>>>>       <nic name="eth0"/>
>>>> </interface>
>>>>
>>>> The 'name' attribute also allows expressions:
>>>>
>>>> <nic name="${my.public.nic:eth0}"/>
>>>>
>>>> With that kind of config, the JMX query Filippe showed will provide a
>>>> regular address.
>>>>
>>>> [1] The CLI op:
>>>>
>>>> [standalone at localhost:9990 /]
>>>>
>>>> /socket-binding-group=standard-sockets/socket-binding=http:read-attribute(name=bound-address)
>>>> {
>>>>        "outcome" => "success",
>>>>        "result" => "0.0.0.0"
>>>> }
>>>>
>>>> On 9/1/15 12:25 PM, Filippe spolti wrote:
>>>>>
>>>>> Hello Arun,
>>>>>
>>>>> I usethis code w/ Jboss 7 and wildfly 8, i didn't test with wildfly
>>>>> 9/10.
>>>>>
>>>>>            MBeanServer mBeanServer =
>>>>> ManagementFactory.getPlatformMBeanServer();
>>>>>            String url = null;
>>>>>            try {
>>>>>
>>>>>                ObjectName http = new
>>>>>
>>>>> ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=http");
>>>>>                String jbossHttpAddress = (String)
>>>>> mBeanServer.getAttribute(http,"boundAddress");
>>>>>                int jbossHttpPort = (Integer)
>>>>> mBeanServer.getAttribute(http,"boundPort");
>>>>>                url = jbossHttpAddress + ":" + jbossHttpPort;
>>>>>                log.fine("Url obtained from the system: " + url);
>>>>>            } catch (Exception e) {
>>>>>                log.severe(e.getStackTrace().toString());
>>>>>            }
>>>>>            return url;
>>>>>
>>>>> regards.
>>>>>
>>>>>
>>>>> On 09/01/2015 02:20 PM, Arun Gupta wrote:
>>>>>>
>>>>>> Assuming WildFly is bound to all available IP addresses using -b
>>>>>> 0.0.0.0, is there a WildFly-specific API that can be used to obtain
>>>>>> the IP address where the server is running?
>>>>>>
>>>>>> Ideally, I'd like something like:
>>>>>>
>>>>>> WildFly.getHostAddress()
>>>>>> WildFly.getHostPort()
>>>>>>
>>>>>> It could be running in a Docker container, in AWS, on my local laptop,
>>>>>> in OpenShift, or any where else and would like the IP address to be
>>>>>> returned correctly.
>>>>>>
>>>>>> Suggestions?
>>>>>>
>>>>>> Arun
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Senior Principal Software Engineer
>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Brian Stansberry
>> Senior Principal Software Engineer
>> JBoss by Red Hat
>
>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From arun.gupta at gmail.com  Tue Sep  1 19:52:31 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Tue, 1 Sep 2015 16:52:31 -0700
Subject: [wildfly-dev] WildFly Server IP Address and Port
In-Reply-To: <55E62F7C.8070204@redhat.com>
References: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>
	<55E5DF79.7090207@gmail.com> <55E60B2D.5040407@redhat.com>
	<CAGBoHQXWhgmGgj=Y0NeNFJm3QfYLTk-Q=hyrwEaY5yzj0E6pMw@mail.gmail.com>
	<55E627D6.1050904@redhat.com>
	<CAGBoHQWUu169VE28860=3nf1peVnAUKqOxgVFP8zWN-M7zFBvQ@mail.gmail.com>
	<55E62F7C.8070204@redhat.com>
Message-ID: <CAGBoHQWJV1v6GRkD1BUSt=3bLdS8sAS8T6DXhWXofhu11D=Aww@mail.gmail.com>

>>> Is this scenario different from running multiple WildFly instances on a
>>> single machine in a non-Docker setup?
>>
>>
>> Good point, they are the same.
>>
>
> Reading a bit more, it seems Docker gives each container its own address,
> visible to the container via the eth0 interface:
>
> https://docs.docker.com/articles/networking/

Those IP addresses are not available externally AIU.

>> So, if WildFly runs with -b <IP_ADDRESS> then the utility above will
>> give the correct address and port?
>>
>
> Yes, assuming IP_ADDRESS != 0.0.0.0, the server config is using a
> socket-binding named "http" for the web server, and the web server
> address/port is the one you want.
>

            ObjectName http = new
ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=http");
            hostName = (String) mBeanServer.getAttribute(http,"boundAddress");
            hostPort = (Integer) mBeanServer.getAttribute(http,"boundPort");


seems to be returning correct HTTP host/port. However

            ObjectName https = new
ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=https");
            hostSecurePort = (int) mBeanServer.getAttribute(https, "boundPort");

is throwing NPE.

Will this only be available if HTTPS port is accessible?

Arun



-- 
http://blog.arungupta.me
http://twitter.com/arungupta

From brian.stansberry at redhat.com  Wed Sep  2 09:20:57 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 2 Sep 2015 08:20:57 -0500
Subject: [wildfly-dev] WildFly Server IP Address and Port
In-Reply-To: <CAGBoHQWJV1v6GRkD1BUSt=3bLdS8sAS8T6DXhWXofhu11D=Aww@mail.gmail.com>
References: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>
	<55E5DF79.7090207@gmail.com> <55E60B2D.5040407@redhat.com>
	<CAGBoHQXWhgmGgj=Y0NeNFJm3QfYLTk-Q=hyrwEaY5yzj0E6pMw@mail.gmail.com>
	<55E627D6.1050904@redhat.com>
	<CAGBoHQWUu169VE28860=3nf1peVnAUKqOxgVFP8zWN-M7zFBvQ@mail.gmail.com>
	<55E62F7C.8070204@redhat.com>
	<CAGBoHQWJV1v6GRkD1BUSt=3bLdS8sAS8T6DXhWXofhu11D=Aww@mail.gmail.com>
Message-ID: <55E6F7B9.5070707@redhat.com>

On 9/1/15 6:52 PM, Arun Gupta wrote:
>>>> Is this scenario different from running multiple WildFly instances on a
>>>> single machine in a non-Docker setup?
>>>
>>>
>>> Good point, they are the same.
>>>
>>
>> Reading a bit more, it seems Docker gives each container its own address,
>> visible to the container via the eth0 interface:
>>
>> https://docs.docker.com/articles/networking/
>
> Those IP addresses are not available externally AIU.
>

Ok, I'm getting clear on your scenario. Thanks.

>>> So, if WildFly runs with -b <IP_ADDRESS> then the utility above will
>>> give the correct address and port?
>>>
>>
>> Yes, assuming IP_ADDRESS != 0.0.0.0, the server config is using a
>> socket-binding named "http" for the web server, and the web server
>> address/port is the one you want.
>>
>
>              ObjectName http = new
> ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=http");
>              hostName = (String) mBeanServer.getAttribute(http,"boundAddress");
>              hostPort = (Integer) mBeanServer.getAttribute(http,"boundPort");
>
>
> seems to be returning correct HTTP host/port. However
>
>              ObjectName https = new
> ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=https");
>              hostSecurePort = (int) mBeanServer.getAttribute(https, "boundPort");
>
> is throwing NPE.
>
> Will this only be available if HTTPS port is accessible?
>

Those attributes will only be non-null if the https socket-binding is 
used by some service (e.g. an undertow listener.) If the configuration 
doesn't require the socket binding to be used, then the resolution of 
the socket binding's config data to an actual IP address will not occur.

> Arun
>
>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From bmcwhirt at redhat.com  Wed Sep  2 09:23:44 2015
From: bmcwhirt at redhat.com (Bob McWhirter)
Date: Wed, 2 Sep 2015 10:23:44 -0300
Subject: [wildfly-dev] WildFly Server IP Address and Port
In-Reply-To: <55E6F7B9.5070707@redhat.com>
References: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>
	<55E5DF79.7090207@gmail.com> <55E60B2D.5040407@redhat.com>
	<CAGBoHQXWhgmGgj=Y0NeNFJm3QfYLTk-Q=hyrwEaY5yzj0E6pMw@mail.gmail.com>
	<55E627D6.1050904@redhat.com>
	<CAGBoHQWUu169VE28860=3nf1peVnAUKqOxgVFP8zWN-M7zFBvQ@mail.gmail.com>
	<55E62F7C.8070204@redhat.com>
	<CAGBoHQWJV1v6GRkD1BUSt=3bLdS8sAS8T6DXhWXofhu11D=Aww@mail.gmail.com>
	<55E6F7B9.5070707@redhat.com>
Message-ID: <CA+45JvHJZkNDQv=5DTTvchPj26LwEneLfADk9TpsBBduf34c5Q@mail.gmail.com>

We do support some way to advertise (via jgroups) a different host/port
than the one that it is actually bound to, right?

I thought we had to add that functionality to support OpenShift, where the
internal IP given to the AS is different than the externally visible
host/port for clustering.

On Wed, Sep 2, 2015 at 10:20 AM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> On 9/1/15 6:52 PM, Arun Gupta wrote:
> >>>> Is this scenario different from running multiple WildFly instances on
> a
> >>>> single machine in a non-Docker setup?
> >>>
> >>>
> >>> Good point, they are the same.
> >>>
> >>
> >> Reading a bit more, it seems Docker gives each container its own
> address,
> >> visible to the container via the eth0 interface:
> >>
> >> https://docs.docker.com/articles/networking/
> >
> > Those IP addresses are not available externally AIU.
> >
>
> Ok, I'm getting clear on your scenario. Thanks.
>
> >>> So, if WildFly runs with -b <IP_ADDRESS> then the utility above will
> >>> give the correct address and port?
> >>>
> >>
> >> Yes, assuming IP_ADDRESS != 0.0.0.0, the server config is using a
> >> socket-binding named "http" for the web server, and the web server
> >> address/port is the one you want.
> >>
> >
> >              ObjectName http = new
> > ObjectName("jboss.as:
> socket-binding-group=standard-sockets,socket-binding=http");
> >              hostName = (String)
> mBeanServer.getAttribute(http,"boundAddress");
> >              hostPort = (Integer)
> mBeanServer.getAttribute(http,"boundPort");
> >
> >
> > seems to be returning correct HTTP host/port. However
> >
> >              ObjectName https = new
> > ObjectName("jboss.as:
> socket-binding-group=standard-sockets,socket-binding=https");
> >              hostSecurePort = (int) mBeanServer.getAttribute(https,
> "boundPort");
> >
> > is throwing NPE.
> >
> > Will this only be available if HTTPS port is accessible?
> >
>
> Those attributes will only be non-null if the https socket-binding is
> used by some service (e.g. an undertow listener.) If the configuration
> doesn't require the socket binding to be used, then the resolution of
> the socket binding's config data to an actual IP address will not occur.
>
> > Arun
> >
> >
> >
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150902/0783d5be/attachment-0001.html 

From emmanuel at hibernate.org  Wed Sep  2 10:37:47 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 2 Sep 2015 16:37:47 +0200
Subject: [wildfly-dev] Upcoming WF10 Dates (Reminder)
In-Reply-To: <627F9528-0957-49B6-8DDB-E4D6A4138AEF@redhat.com>
References: <627F9528-0957-49B6-8DDB-E4D6A4138AEF@redhat.com>
Message-ID: <994C8CC0-A6BB-4B55-AD0F-93CD161724B9@hibernate.org>

Hey,

Just a quick heads up on Hibernate Search.

We are planning to get our 5.5 Final in time for Sept 9th and WildFly CR1. But there is a small chance that we split a bit and that we would only get a CR in time for WildFly CR1. We?re working on the easier solution of course :)

Emmanuel



> On 13 Aug 2015, at 19:42, Jason Greene <jason.greene at redhat.com> wrote:
> 
> Hello Everyone,
> 
> First off, I just wanted to say thank you everyone for hitting the major deliverables for the WF10 Beta release that went out over the weekend! 
> 
> The remaining schedule for WF10 is as follows:
> 
> WildFly 10 CR1              - September 9th  
> WildFly 10 CR2 (if needed)  - September 16th 
> WildFly 10 Final            - October 8th (contigent on certification)
> 
> So that means we have 26 days (17 workdays left) to:
> 
> - Stabilize features brought in during Alpha/Beta cycle
> - Finish/polish compatibility (transformers, management ops, etc)
> - Upgrade all components to Final (preferable) or CR (exceptional)
> - Fix broken and/or intermittent tests relating to the above
> - Address any other loose ends
> 
> We should avoid (if possible) introducing new major features to allow for enough time to do the above. Let me know ASAP if thats a problem.
> 
> Thanks!
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From brian.stansberry at redhat.com  Wed Sep  2 16:42:51 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 2 Sep 2015 15:42:51 -0500
Subject: [wildfly-dev] WildFly Server IP Address and Port
In-Reply-To: <CA+45JvHJZkNDQv=5DTTvchPj26LwEneLfADk9TpsBBduf34c5Q@mail.gmail.com>
References: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>
	<55E5DF79.7090207@gmail.com> <55E60B2D.5040407@redhat.com>
	<CAGBoHQXWhgmGgj=Y0NeNFJm3QfYLTk-Q=hyrwEaY5yzj0E6pMw@mail.gmail.com>
	<55E627D6.1050904@redhat.com>
	<CAGBoHQWUu169VE28860=3nf1peVnAUKqOxgVFP8zWN-M7zFBvQ@mail.gmail.com>
	<55E62F7C.8070204@redhat.com>
	<CAGBoHQWJV1v6GRkD1BUSt=3bLdS8sAS8T6DXhWXofhu11D=Aww@mail.gmail.com>
	<55E6F7B9.5070707@redhat.com>
	<CA+45JvHJZkNDQv=5DTTvchPj26LwEneLfADk9TpsBBduf34c5Q@mail.gmail.com>
Message-ID: <55E75F4B.20508@redhat.com>

I believe you are referring to the "external_addr" configuration 
property available for JGroups transport protocols:

http://www.jgroups.org/manual/html/protlist.html#Transport

I didn't follow the development of that feature in detail, but I assume 
the way it works is the JGroups discovery protocols advertise the value 
of that property if it's configured. Otherwise they advertise the usual 
bind_addr.

That's specific to JGroups discovery though. It's not a general purpose 
service endpoint publication and discovery thing. I've seen systems like 
Kubernetes used for that kind of orchestration.

On 9/2/15 8:23 AM, Bob McWhirter wrote:
> We do support some way to advertise (via jgroups) a different host/port
> than the one that it is actually bound to, right?
>
> I thought we had to add that functionality to support OpenShift, where
> the internal IP given to the AS is different than the externally visible
> host/port for clustering.
>
> On Wed, Sep 2, 2015 at 10:20 AM, Brian Stansberry
> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
>
>     On 9/1/15 6:52 PM, Arun Gupta wrote:
>     >>>> Is this scenario different from running multiple WildFly instances on a
>     >>>> single machine in a non-Docker setup?
>     >>>
>     >>>
>     >>> Good point, they are the same.
>     >>>
>     >>
>     >> Reading a bit more, it seems Docker gives each container its own address,
>     >> visible to the container via the eth0 interface:
>     >>
>     >>https://docs.docker.com/articles/networking/
>     >
>     > Those IP addresses are not available externally AIU.
>     >
>
>     Ok, I'm getting clear on your scenario. Thanks.
>
>     >>> So, if WildFly runs with -b <IP_ADDRESS> then the utility above will
>     >>> give the correct address and port?
>     >>>
>     >>
>     >> Yes, assuming IP_ADDRESS != 0.0.0.0, the server config is using a
>     >> socket-binding named "http" for the web server, and the web server
>     >> address/port is the one you want.
>     >>
>     >
>     >              ObjectName http = new
>     > ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=http");
>     >              hostName = (String) mBeanServer.getAttribute(http,"boundAddress");
>     >              hostPort = (Integer) mBeanServer.getAttribute(http,"boundPort");
>     >
>     >
>     > seems to be returning correct HTTP host/port. However
>     >
>     >              ObjectName https = new
>     > ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=https");
>     >              hostSecurePort = (int) mBeanServer.getAttribute(https, "boundPort");
>     >
>     > is throwing NPE.
>     >
>     > Will this only be available if HTTPS port is accessible?
>     >
>
>     Those attributes will only be non-null if the https socket-binding is
>     used by some service (e.g. an undertow listener.) If the configuration
>     doesn't require the socket binding to be used, then the resolution of
>     the socket binding's config data to an actual IP address will not occur.
>
>      > Arun
>     >
>     >
>     >
>
>
>     --
>     Brian Stansberry
>     Senior Principal Software Engineer
>     JBoss by Red Hat
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From arun.gupta at gmail.com  Wed Sep  2 18:35:44 2015
From: arun.gupta at gmail.com (Arun Gupta)
Date: Wed, 2 Sep 2015 15:35:44 -0700
Subject: [wildfly-dev] WildFly Server IP Address and Port
In-Reply-To: <55E6F7B9.5070707@redhat.com>
References: <CAGBoHQXtnO7R5BH-a+ZbQSY8CSbt1EV8K+y-XLmmbsP_zXnQrw@mail.gmail.com>
	<55E5DF79.7090207@gmail.com> <55E60B2D.5040407@redhat.com>
	<CAGBoHQXWhgmGgj=Y0NeNFJm3QfYLTk-Q=hyrwEaY5yzj0E6pMw@mail.gmail.com>
	<55E627D6.1050904@redhat.com>
	<CAGBoHQWUu169VE28860=3nf1peVnAUKqOxgVFP8zWN-M7zFBvQ@mail.gmail.com>
	<55E62F7C.8070204@redhat.com>
	<CAGBoHQWJV1v6GRkD1BUSt=3bLdS8sAS8T6DXhWXofhu11D=Aww@mail.gmail.com>
	<55E6F7B9.5070707@redhat.com>
Message-ID: <CAGBoHQUUaMAzfAAZ+nzLq8MWgfD7BTUwCtWAe90kt1L5O_BLTw@mail.gmail.com>

Next issue with this usage ...

Starting the command "/opt/jboss/wildfly/bin/standalone.sh -b
192.168.99.100" inside the container gives the following error ...

22:27:00,265 INFO  [org.xnio.nio] (MSC service thread 1-2) XNIO NIO
Implementation Version 3.3.1.Final
22:27:00,287 ERROR [org.jboss.msc.service.fail] (MSC service thread
1-1) MSC000001: Failed to start service jboss.network.public:
org.jboss.msc.service.StartException in service jboss.network.public:
WFLYSRV0082: failed to resolve interface public
at org.jboss.as.server.services.net.NetworkInterfaceService.start(NetworkInterfaceService.java:91)
[wildfly-server-1.0.1.Final.jar:1.0.1.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
[jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
[jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[rt.jar:1.8.0_51]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[rt.jar:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_51]

This is expected because 192.168.99.100 is IP Address of Docker Host.
Seems like I may have to use the internal IP address. Any thoughts on
how to obtain it?

And even then, not sure if this will allow jboss-cli to return the
publicly exposed IP address, i.e. of Docker Host.

Thoughts?

Arun

On Wed, Sep 2, 2015 at 6:20 AM, Brian Stansberry
<brian.stansberry at redhat.com> wrote:
> On 9/1/15 6:52 PM, Arun Gupta wrote:
>>>>>
>>>>> Is this scenario different from running multiple WildFly instances on a
>>>>> single machine in a non-Docker setup?
>>>>
>>>>
>>>>
>>>> Good point, they are the same.
>>>>
>>>
>>> Reading a bit more, it seems Docker gives each container its own address,
>>> visible to the container via the eth0 interface:
>>>
>>> https://docs.docker.com/articles/networking/
>>
>>
>> Those IP addresses are not available externally AIU.
>>
>
> Ok, I'm getting clear on your scenario. Thanks.
>
>>>> So, if WildFly runs with -b <IP_ADDRESS> then the utility above will
>>>> give the correct address and port?
>>>>
>>>
>>> Yes, assuming IP_ADDRESS != 0.0.0.0, the server config is using a
>>> socket-binding named "http" for the web server, and the web server
>>> address/port is the one you want.
>>>
>>
>>              ObjectName http = new
>>
>> ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=http");
>>              hostName = (String)
>> mBeanServer.getAttribute(http,"boundAddress");
>>              hostPort = (Integer)
>> mBeanServer.getAttribute(http,"boundPort");
>>
>>
>> seems to be returning correct HTTP host/port. However
>>
>>              ObjectName https = new
>>
>> ObjectName("jboss.as:socket-binding-group=standard-sockets,socket-binding=https");
>>              hostSecurePort = (int) mBeanServer.getAttribute(https,
>> "boundPort");
>>
>> is throwing NPE.
>>
>> Will this only be available if HTTPS port is accessible?
>>
>
> Those attributes will only be non-null if the https socket-binding is used
> by some service (e.g. an undertow listener.) If the configuration doesn't
> require the socket binding to be used, then the resolution of the socket
> binding's config data to an actual IP address will not occur.
>
>> Arun
>>
>>
>>
>
>
> --
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat



-- 
http://blog.arungupta.me
http://twitter.com/arungupta

From darran.lofthouse at jboss.com  Thu Sep  3 07:06:50 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 3 Sep 2015 12:06:50 +0100
Subject: [wildfly-dev] Perf tip for folks writing management code
In-Reply-To: <55DE1128.6060902@redhat.com>
References: <55DE1128.6060902@redhat.com>
Message-ID: <55E829CA.20500@jboss.com>



On 26/08/15 20:19, Brian Stansberry wrote:
> If you're writing code that manipulates potentially large chunks of the
> management model, be cautious of the following:
>
> 1) org.jboss.as.controller.Registry.Tools.readModel(final Resource resource)
>
> This makes a deep clone of all the DMR model nodes in the given resource
> tree. That may be a good thing, but is expensive with large trees, so be
> aware.
>
> 2) org.jboss.dmr.ModelNode.asPropertyList()
>
> For each Property in the returned list, the 'value' member is a deep
> clone of the corresponding element in the original model node. So, again
> expensive with large trees, so be aware.
>
> You can replace this:
>
> for (Property prop : node.asPropertyList() {
>      String name = prop.getName();
>      ModelNode value = prop.getValue();
>      ... do something with name and value
> }
>
> with
>
> for (String name : node.keys()) {
>       ModelNode value = node.get(name);

For this line would it be better to use 'require'?  It should not be 
possible for it to be undefined but require would check that.

>       ... do something with name and value
> }
>
> I'll fix a few high impact cases of this usage.
>
> Please resist the urge to send in lots of refactoring PRs until WF 10 is
> done. ;)
>

From stuart.w.douglas at gmail.com  Thu Sep  3 08:43:52 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Thu, 03 Sep 2015 12:43:52 +0000
Subject: [wildfly-dev] Adding permissions to tests
Message-ID: <CAAoo=c6BtA2KOHdXcoQQ=ntzaJ2MixEtXhdxskT1QjCr5U224Q@mail.gmail.com>

Hi everyone,

There have been a few PR's lately that add permissions to tests via
permissions.xml so that they pass under the security manager.

The security manager focus is great, however if you are submitting a PR
like this it would make reviewers jobs much easier if you include a simple
justification of why the test needs the permission.

Basically if we have a permissions problem in our code we should not just
be covering it up via permissions.xml in our tests, and as a reviewer is
very hard to tell which permissions are genuinely needed.

Ideally this will take the form of the problematic stack trace in the PR,
although if the test just needs a permission to do something test specific
(like reading the ts.timeout.factor property) then a simple comment will
suffice.

Thanks,

Stuart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150903/6d10236b/attachment.html 

From okotek at redhat.com  Thu Sep  3 08:47:17 2015
From: okotek at redhat.com (Ondrej Kotek)
Date: Thu, 3 Sep 2015 08:47:17 -0400 (EDT)
Subject: [wildfly-dev]  Permissions for Arquillian in test deployments
In-Reply-To: <88315711.28589573.1441283837318.JavaMail.zimbra@redhat.com>
Message-ID: <891397961.28625450.1441284437675.JavaMail.zimbra@redhat.com>

Hi,

I am investigating failing tests in WildFly and WildFly Core testsuites [1,2] when security manager is enabled.

There are test cases using org.jboss.as.arquillian.container.ManagementClient in non-runAsClient mode. While running with Java Security Manager without AllPermission assigned, the test cases fail. This is caused by insufficient permissions assigned to deployments -- deployments require permissions that Arquillian uses to create connection for ManagementClient, e.g. read FilePermission for modules/system/layers/base/org/jboss/xnio/nio/main/* (XNIO module), connect,resolve SocketPermission, * * MBeanPermission, getClassLoader RuntimePermission.

There are probably about 27 such tests ([1,2] and other related issues).

Adding permissions for Arquillian to a deployment could mask bugs related to such permissions. The demand of permissions for Arquillian should be shielded by Arquillian. Is it doable?

In case it is not doable, there are several other ways how to solve adding permissions for Arquillian:
  * Adding such permissions to minimum-permissions set in security-manager subsystem
  * Adding such permissions to each permissions.xml
  * Creating a custom permission containing such permissions and adding it to each permissions.xml

Which one do you consider the most correct? Or, is there another way?

[1] https://issues.jboss.org/browse/WFLY-5169
[2] https://issues.jboss.org/browse/WFCORE-848

Thanks,

 Ondrej Kotek

From brian.stansberry at redhat.com  Thu Sep  3 09:08:58 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 3 Sep 2015 08:08:58 -0500
Subject: [wildfly-dev] Perf tip for folks writing management code
In-Reply-To: <55E829CA.20500@jboss.com>
References: <55DE1128.6060902@redhat.com> <55E829CA.20500@jboss.com>
Message-ID: <55E8466A.4080600@redhat.com>

On 9/3/15 6:06 AM, Darran Lofthouse wrote:
>
>
> On 26/08/15 20:19, Brian Stansberry wrote:

>> You can replace this:
>>
>> for (Property prop : node.asPropertyList() {
>>       String name = prop.getName();
>>       ModelNode value = prop.getValue();
>>       ... do something with name and value
>> }
>>
>> with
>>
>> for (String name : node.keys()) {
>>        ModelNode value = node.get(name);
>
> For this line would it be better to use 'require'?  It should not be
> possible for it to be undefined but require would check that.
>

There's no requirement that 'value' not be ModelType.UNDEFINED, and the 
'require' method doesn't introduce one either. So calling 'require' 
would just be a confirmation that 'keys()' isn't broken.

ModelNode.asPropertyList() also (correctly) doesn't include any checks 
that the values in the properties are defined.

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From brian.stansberry at redhat.com  Thu Sep  3 11:28:25 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 3 Sep 2015 10:28:25 -0500
Subject: [wildfly-dev] Permissions for Arquillian in test deployments
In-Reply-To: <891397961.28625450.1441284437675.JavaMail.zimbra@redhat.com>
References: <891397961.28625450.1441284437675.JavaMail.zimbra@redhat.com>
Message-ID: <55E86719.8050007@redhat.com>

I don't have much of a comment re: the Arquillian issue, but for the 
WFCORE ones the deployments need to have a permissions.xml that lets 
them function. Those aren't a case of the test client logic being mixed 
in with the deployment logic.

Altering the 'default' permissions by adding such permissions to the 
minimum-permissions set in security-manager subsystem sounds wrong, for 
the reasons Stuart describes in his "Adding permissions to tests" thread 
today. It's more likely to mask real problems. That kind of change would 
need to be done and reverted via a ServerSetupTask for each test, so it 
doesn't have a large advantage in terms of ease of implementation.

BTW if any of the tests in full are not @RunAsClient but could be, they 
should be changed. But if there are only 27 relevant tests, the odds are 
good the bulk of such tests have been fixed.

On 9/3/15 7:47 AM, Ondrej Kotek wrote:
> Hi,
>
> I am investigating failing tests in WildFly and WildFly Core testsuites [1,2] when security manager is enabled.
>
> There are test cases using org.jboss.as.arquillian.container.ManagementClient in non-runAsClient mode. While running with Java Security Manager without AllPermission assigned, the test cases fail. This is caused by insufficient permissions assigned to deployments -- deployments require permissions that Arquillian uses to create connection for ManagementClient, e.g. read FilePermission for modules/system/layers/base/org/jboss/xnio/nio/main/* (XNIO module), connect,resolve SocketPermission, * * MBeanPermission, getClassLoader RuntimePermission.
>
> There are probably about 27 such tests ([1,2] and other related issues).
>
> Adding permissions for Arquillian to a deployment could mask bugs related to such permissions. The demand of permissions for Arquillian should be shielded by Arquillian. Is it doable?
>
> In case it is not doable, there are several other ways how to solve adding permissions for Arquillian:
>    * Adding such permissions to minimum-permissions set in security-manager subsystem
>    * Adding such permissions to each permissions.xml
>    * Creating a custom permission containing such permissions and adding it to each permissions.xml
>
> Which one do you consider the most correct? Or, is there another way?
>
> [1] https://issues.jboss.org/browse/WFLY-5169
> [2] https://issues.jboss.org/browse/WFCORE-848
>
> Thanks,
>
>   Ondrej Kotek
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From alexey.loubyansky at redhat.com  Thu Sep  3 11:42:05 2015
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Thu, 03 Sep 2015 17:42:05 +0200
Subject: [wildfly-dev] CLI batches in control flow blocks
Message-ID: <55E86A4D.80809@redhat.com>

Hello everyone,

I've been thinking about changing how the bodies of if-else and 
try-catch-finally are treated by the CLI.

Up until now every control flow block (i.e. between if and else, between 
else and end-if, etc) was executed as a batch. So, when a block was 
selected for the execution, the CLI would enter the batch mode and 
proceed adding operations (and commands translated to operations) to it. 
If a command can't be translated to an operation, it would be executed 
outside the batch immediately (that's done for commands like cd, ls, 
etc). After the last line of the body processed, the batch (if not 
empty) is executed.

But this doesn't work when mixing operations with shutdown or reload 
commands (they do translate to operations but they have additional logic 
related to re-connecting). shutdown/reload will be executed outside the 
batch and before the batch is complete.

Currently open issues for this
https://issues.jboss.org/browse/WFCORE-876
https://issues.jboss.org/browse/WFCORE-533

So, I think it was a mistake to execute the bodies of control flow 
blocks as batches. It would be better leave them as usual sequences of 
command lines and if the user wants a batch, he/she could add batch 
command explicitly.

I wanted to ask for opinions. Could we make this change in WildFly 10?

Thanks,
Alexey

From tomaz.cerar at gmail.com  Thu Sep  3 12:01:02 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 3 Sep 2015 18:01:02 +0200
Subject: [wildfly-dev] Permissions for Arquillian in test deployments
In-Reply-To: <891397961.28625450.1441284437675.JavaMail.zimbra@redhat.com>
References: <88315711.28589573.1441283837318.JavaMail.zimbra@redhat.com>
	<891397961.28625450.1441284437675.JavaMail.zimbra@redhat.com>
Message-ID: <CAMquZP41jDPJjYup8saotg0QygoC4A3a16_YKcuoKSdL6Nbo_A@mail.gmail.com>

On Thu, Sep 3, 2015 at 2:47 PM, Ondrej Kotek <okotek at redhat.com> wrote:

> There are test cases using
> org.jboss.as.arquillian.container.ManagementClient in non-runAsClient mode.
> While running with Java Security Manager without AllPermission assigned,
> the test cases fail. This is caused by insufficient permissions assigned to
> deployments -- deployments require permissions that Arquillian uses to
> create connection for ManagementClient, e.g. read FilePermission for
> modules/system/layers/base/org/jboss/xnio/nio/main/* (XNIO module),
> connect,resolve SocketPermission, * * MBeanPermission, getClassLoader
> RuntimePermission.
>

Just line of note here, ManagmentClient class you see in WildFly core tests
is not from Arquillian but WildFly core test runner.
see
https://github.com/wildfly/wildfly-core/tree/master/testsuite/test-runner/src/main/java/org/wildfly/core/testrunner

and as such, permissions could be added there at this is only used for
wildfly core testsuite.
Also, core doesn't have any dependencies to arquillian.


--
tomaz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150903/cf96199a/attachment.html 

From tomaz.cerar at gmail.com  Thu Sep  3 12:25:23 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 3 Sep 2015 18:25:23 +0200
Subject: [wildfly-dev] WildFly PR testing notification changes
Message-ID: <CAMquZP5N1dUgazOYqygzUc5J_LU3g6yxKVR8v1t_z5nSURapuA@mail.gmail.com>

Hey guys,

this mail is just heads up about recent changes to our CI <-->  GitHub PR
integration.

As we started adding more and more different jobs to test each PR number of
comments
on each PR became almost like spam as each job added one comment when it
started
and second one with report of the build.

With changes we did in past few weeks, we now have:

- all build statuses only as part of github PR status check [1]
- comments get added only when there is build failure
- usual, retest this please & friends still work as they use to
- *in testing* auto lableling / unlabling of rebase-this/fixme lables.

So to see the actual status of the builds and if all checks passed,
you will need to look at the pull request itself and not only mail
notifications like till now.

--
tomaz


[1]
https://github.com/blog/1935-see-results-from-all-pull-request-status-checks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150903/64588cc4/attachment.html 

From akostadi at redhat.com  Thu Sep  3 14:48:48 2015
From: akostadi at redhat.com (Aleksandar Kostadinov)
Date: Thu, 3 Sep 2015 21:48:48 +0300
Subject: [wildfly-dev] WildFly PR testing notification changes
In-Reply-To: <CAMquZP5N1dUgazOYqygzUc5J_LU3g6yxKVR8v1t_z5nSURapuA@mail.gmail.com>
References: <CAMquZP5N1dUgazOYqygzUc5J_LU3g6yxKVR8v1t_z5nSURapuA@mail.gmail.com>
Message-ID: <55E89610.9030003@redhat.com>

Is there any document describing wildfly PR review process? Blog, 
diagram, etc.

Toma? Cerar wrote on 09/03/2015 07:25 PM:
> Hey guys,
>
> this mail is just heads up about recent changes to our CI <-->  GitHub
> PR integration.
>
> As we started adding more and more different jobs to test each PR number
> of comments
> on each PR became almost like spam as each job added one comment when it
> started
> and second one with report of the build.
>
> With changes we did in past few weeks, we now have:
>
> - all build statuses only as part of github PR status check [1]
> - comments get added only when there is build failure
> - usual, retest this please & friends still work as they use to
> - *in testing* auto lableling / unlabling of rebase-this/fixme lables.
>
> So to see the actual status of the builds and if all checks passed,
> you will need to look at the pull request itself and not only mail
> notifications like till now.
>
> --
> tomaz
>
>
> [1]
> https://github.com/blog/1935-see-results-from-all-pull-request-status-checks
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From tomaz.cerar at gmail.com  Thu Sep  3 17:39:43 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 3 Sep 2015 23:39:43 +0200
Subject: [wildfly-dev] WildFly PR testing notification changes
In-Reply-To: <55E89610.9030003@redhat.com>
References: <CAMquZP5N1dUgazOYqygzUc5J_LU3g6yxKVR8v1t_z5nSURapuA@mail.gmail.com>
	<55E89610.9030003@redhat.com>
Message-ID: <CAMquZP6ELbYqjnPnHX6wBnc2c3h8OhfoQuNqkLE0xjcckFL_8A@mail.gmail.com>

there was recent post on this mailing list on exact this topic.

this was outcome:
https://developer.jboss.org/wiki/WildFlyPullRequestStandardsAndGuidelines


--
tomaz

On Thu, Sep 3, 2015 at 8:48 PM, Aleksandar Kostadinov <akostadi at redhat.com>
wrote:

> Is there any document describing wildfly PR review process? Blog, diagram,
> etc.
>
>
> Toma? Cerar wrote on 09/03/2015 07:25 PM:
>
>> Hey guys,
>>
>> this mail is just heads up about recent changes to our CI <-->  GitHub
>> PR integration.
>>
>> As we started adding more and more different jobs to test each PR number
>> of comments
>> on each PR became almost like spam as each job added one comment when it
>> started
>> and second one with report of the build.
>>
>> With changes we did in past few weeks, we now have:
>>
>> - all build statuses only as part of github PR status check [1]
>> - comments get added only when there is build failure
>> - usual, retest this please & friends still work as they use to
>> - *in testing* auto lableling / unlabling of rebase-this/fixme lables.
>>
>> So to see the actual status of the builds and if all checks passed,
>> you will need to look at the pull request itself and not only mail
>> notifications like till now.
>>
>> --
>> tomaz
>>
>>
>> [1]
>>
>> https://github.com/blog/1935-see-results-from-all-pull-request-status-checks
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150903/8e2b805e/attachment.html 

From jason.greene at redhat.com  Thu Sep  3 17:42:32 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Thu, 3 Sep 2015 17:42:32 -0400 (EDT)
Subject: [wildfly-dev] WildFly PR testing notification changes
In-Reply-To: <CAMquZP6ELbYqjnPnHX6wBnc2c3h8OhfoQuNqkLE0xjcckFL_8A@mail.gmail.com>
References: <CAMquZP5N1dUgazOYqygzUc5J_LU3g6yxKVR8v1t_z5nSURapuA@mail.gmail.com>
	<55E89610.9030003@redhat.com>
	<CAMquZP6ELbYqjnPnHX6wBnc2c3h8OhfoQuNqkLE0xjcckFL_8A@mail.gmail.com>
Message-ID: <C7886F85-4806-4464-9036-CA6D036F13F6@redhat.com>

Also the how to submit which is linked:

https://developer.jboss.org/wiki/HackingOnWildFly

> On Sep 3, 2015, at 4:40 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> 
> there was recent post on this mailing list on exact this topic.
> 
> this was outcome:
> https://developer.jboss.org/wiki/WildFlyPullRequestStandardsAndGuidelines
> 
> 
> --
> tomaz
> 
>> On Thu, Sep 3, 2015 at 8:48 PM, Aleksandar Kostadinov <akostadi at redhat.com> wrote:
>> Is there any document describing wildfly PR review process? Blog, diagram, etc.
>> 
>> 
>> Toma? Cerar wrote on 09/03/2015 07:25 PM:
>>> Hey guys,
>>> 
>>> this mail is just heads up about recent changes to our CI <-->  GitHub
>>> PR integration.
>>> 
>>> As we started adding more and more different jobs to test each PR number
>>> of comments
>>> on each PR became almost like spam as each job added one comment when it
>>> started
>>> and second one with report of the build.
>>> 
>>> With changes we did in past few weeks, we now have:
>>> 
>>> - all build statuses only as part of github PR status check [1]
>>> - comments get added only when there is build failure
>>> - usual, retest this please & friends still work as they use to
>>> - *in testing* auto lableling / unlabling of rebase-this/fixme lables.
>>> 
>>> So to see the actual status of the builds and if all checks passed,
>>> you will need to look at the pull request itself and not only mail
>>> notifications like till now.
>>> 
>>> --
>>> tomaz
>>> 
>>> 
>>> [1]
>>> https://github.com/blog/1935-see-results-from-all-pull-request-status-checks
>>> 
>>> 
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150903/fb10df6d/attachment-0001.html 

From akostadi at redhat.com  Thu Sep  3 17:52:13 2015
From: akostadi at redhat.com (Aleksandar Kostadinov)
Date: Fri, 4 Sep 2015 00:52:13 +0300
Subject: [wildfly-dev] WildFly PR testing notification changes
In-Reply-To: <C7886F85-4806-4464-9036-CA6D036F13F6@redhat.com>
References: <CAMquZP5N1dUgazOYqygzUc5J_LU3g6yxKVR8v1t_z5nSURapuA@mail.gmail.com>
	<55E89610.9030003@redhat.com>
	<CAMquZP6ELbYqjnPnHX6wBnc2c3h8OhfoQuNqkLE0xjcckFL_8A@mail.gmail.com>
	<C7886F85-4806-4464-9036-CA6D036F13F6@redhat.com>
Message-ID: <55E8C10D.8000703@redhat.com>

I was asking about a description of the whole PR/review process e.g.
https://www.previousnext.com.au/blog/automated-drupal-testing-github-pull-requests

Might be useful for others to adopt similar practices.

Jason T. Greene wrote on 09/04/2015 12:42 AM:
> Also the how to submit which is linked:
>
> https://developer.jboss.org/wiki/HackingOnWildFly
>
> On Sep 3, 2015, at 4:40 PM, Toma? Cerar <tomaz.cerar at gmail.com
> <mailto:tomaz.cerar at gmail.com>> wrote:
>
>> there was recent post on this mailing list on exact this topic.
>>
>> this was outcome:
>> https://developer.jboss.org/wiki/WildFlyPullRequestStandardsAndGuidelines
>>
>>
>> --
>> tomaz
>>
>> On Thu, Sep 3, 2015 at 8:48 PM, Aleksandar Kostadinov
>> <akostadi at redhat.com <mailto:akostadi at redhat.com>> wrote:
>>
>>     Is there any document describing wildfly PR review process? Blog,
>>     diagram, etc.
>>
>>
>>     Toma? Cerar wrote on 09/03/2015 07:25 PM:
>>
>>         Hey guys,
>>
>>         this mail is just heads up about recent changes to our CI
>>         <-->  GitHub
>>         PR integration.
>>
>>         As we started adding more and more different jobs to test each
>>         PR number
>>         of comments
>>         on each PR became almost like spam as each job added one
>>         comment when it
>>         started
>>         and second one with report of the build.
>>
>>         With changes we did in past few weeks, we now have:
>>
>>         - all build statuses only as part of github PR status check [1]
>>         - comments get added only when there is build failure
>>         - usual, retest this please & friends still work as they use to
>>         - *in testing* auto lableling / unlabling of rebase-this/fixme
>>         lables.
>>
>>         So to see the actual status of the builds and if all checks
>>         passed,
>>         you will need to look at the pull request itself and not only mail
>>         notifications like till now.
>>
>>         --
>>         tomaz
>>
>>
>>         [1]
>>         https://github.com/blog/1935-see-results-from-all-pull-request-status-checks
>>
>>
>>         _______________________________________________
>>         wildfly-dev mailing list
>>         wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From brian.stansberry at redhat.com  Thu Sep  3 18:10:02 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 3 Sep 2015 17:10:02 -0500
Subject: [wildfly-dev] CLI batches in control flow blocks
In-Reply-To: <55E86A4D.80809@redhat.com>
References: <55E86A4D.80809@redhat.com>
Message-ID: <55E8C53A.6040207@redhat.com>

The risk is this can break existing scripts, which we've sought to 
avoid. A couple breakage scenarios:

1) Step 1 needs to happen in a batch with Step 2; now it won't so the 
script breaks.
2) Step 1 works but for some reason Step 2 fails, and now Step 1 isn't 
rolled back.

The first one is more likely, but the second one is a bigger concern, as 
the user may not be aware Step 1 wasn't rolled back.

Do you have any sense of how common either of those scenarios would be?


Below are bad ideas that I wrote down and then thought better of, but 
I'll send them in case it sparks a thought.

I. Since there is already logic for dropping out of the batch for things 
like cd, ls, could it be modified as follows?

a) Close any current batch and execute that batch.
b) Execute the cd, ls, etc
c) Proceed, and if the next statement isn't a cd, ls etc, start a new batch.

That seems like a better semantic for cd and ls anyway.

With that, reload and shutdown can be treated the same as cd, ls.

Why a bad idea? Doing it as I suggest has the same two drawbacks as 
requiring the user to declare the batch. :( Just perhaps less likely to 
occur.

II. Is an --auto-batch=true|false param to if/else/try/catch/finally 
possible? Why a bad idea? To solve the breakage problem it would need to 
be 'true' by default, thus forcing users forever to declare that they 
want the non-broken mode, *plus* they have to declare the batches.


On 9/3/15 10:42 AM, Alexey Loubyansky wrote:
> Hello everyone,
>
> I've been thinking about changing how the bodies of if-else and
> try-catch-finally are treated by the CLI.
>
> Up until now every control flow block (i.e. between if and else, between
> else and end-if, etc) was executed as a batch. So, when a block was
> selected for the execution, the CLI would enter the batch mode and
> proceed adding operations (and commands translated to operations) to it.
> If a command can't be translated to an operation, it would be executed
> outside the batch immediately (that's done for commands like cd, ls,
> etc). After the last line of the body processed, the batch (if not
> empty) is executed.
>
> But this doesn't work when mixing operations with shutdown or reload
> commands (they do translate to operations but they have additional logic
> related to re-connecting). shutdown/reload will be executed outside the
> batch and before the batch is complete.
>
> Currently open issues for this
> https://issues.jboss.org/browse/WFCORE-876
> https://issues.jboss.org/browse/WFCORE-533
>
> So, I think it was a mistake to execute the bodies of control flow
> blocks as batches. It would be better leave them as usual sequences of
> command lines and if the user wants a batch, he/she could add batch
> command explicitly.
>
> I wanted to ask for opinions. Could we make this change in WildFly 10?
>
> Thanks,
> Alexey
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From alexey.loubyansky at redhat.com  Fri Sep  4 01:55:27 2015
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Fri, 04 Sep 2015 07:55:27 +0200
Subject: [wildfly-dev] CLI batches in control flow blocks
In-Reply-To: <55E8C53A.6040207@redhat.com>
References: <55E86A4D.80809@redhat.com> <55E8C53A.6040207@redhat.com>
Message-ID: <55E9324F.5060302@redhat.com>

On 09/04/2015 12:10 AM, Brian Stansberry wrote:
> The risk is this can break existing scripts, which we've sought to
> avoid. A couple breakage scenarios:
>
> 1) Step 1 needs to happen in a batch with Step 2; now it won't so the
> script breaks.
> 2) Step 1 works but for some reason Step 2 fails, and now Step 1 isn't
> rolled back.
>
> The first one is more likely, but the second one is a bigger concern, as
> the user may not be aware Step 1 wasn't rolled back.
>
> Do you have any sense of how common either of those scenarios would be?

Unfortunately, no. I don't get much feedback on this except for created 
issues that I referenced.
I wouldn't bring it up unless this wasn't a major version release, of 
course.

> Below are bad ideas that I wrote down and then thought better of, but
> I'll send them in case it sparks a thought.
>
> I. Since there is already logic for dropping out of the batch for things
> like cd, ls, could it be modified as follows?
>
> a) Close any current batch and execute that batch.
> b) Execute the cd, ls, etc
> c) Proceed, and if the next statement isn't a cd, ls etc, start a new batch.
>
> That seems like a better semantic for cd and ls anyway.

I don't think so. The batch mode is also a composition/editing mode. cd 
and ls are useful when writing commands/operations that should be added 
to the batch. Imagine editing a batch and wishing to cd before entering 
next lines. That won't be possible without explicit holback-batch, cd 
and then batch again. That would be inconvenient.

> With that, reload and shutdown can be treated the same as cd, ls.

For reload and shutdown that does seem to make sense. So, a possible 
alternative is making them exceptions.

> Why a bad idea? Doing it as I suggest has the same two drawbacks as
> requiring the user to declare the batch. :( Just perhaps less likely to
> occur.
>
> II. Is an --auto-batch=true|false param to if/else/try/catch/finally
> possible? Why a bad idea? To solve the breakage problem it would need to
> be 'true' by default, thus forcing users forever to declare that they
> want the non-broken mode, *plus* they have to declare the batches.

As a param to if/else/try/catch/finally this doesn't make sense to me. 
Because then the user could simply explicitly start bodies with batch. 
This kind of argument could make sense as a launching script argument 
for the whole cli session, imo.

Thanks,
Alexey

>
>
> On 9/3/15 10:42 AM, Alexey Loubyansky wrote:
>> Hello everyone,
>>
>> I've been thinking about changing how the bodies of if-else and
>> try-catch-finally are treated by the CLI.
>>
>> Up until now every control flow block (i.e. between if and else, between
>> else and end-if, etc) was executed as a batch. So, when a block was
>> selected for the execution, the CLI would enter the batch mode and
>> proceed adding operations (and commands translated to operations) to it.
>> If a command can't be translated to an operation, it would be executed
>> outside the batch immediately (that's done for commands like cd, ls,
>> etc). After the last line of the body processed, the batch (if not
>> empty) is executed.
>>
>> But this doesn't work when mixing operations with shutdown or reload
>> commands (they do translate to operations but they have additional logic
>> related to re-connecting). shutdown/reload will be executed outside the
>> batch and before the batch is complete.
>>
>> Currently open issues for this
>> https://issues.jboss.org/browse/WFCORE-876
>> https://issues.jboss.org/browse/WFCORE-533
>>
>> So, I think it was a mistake to execute the bodies of control flow
>> blocks as batches. It would be better leave them as usual sequences of
>> command lines and if the user wants a batch, he/she could add batch
>> command explicitly.
>>
>> I wanted to ask for opinions. Could we make this change in WildFly 10?
>>
>> Thanks,
>> Alexey
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>

From tfonteyn at redhat.com  Fri Sep  4 06:36:50 2015
From: tfonteyn at redhat.com (Tom Fonteyne)
Date: Fri, 4 Sep 2015 11:36:50 +0100
Subject: [wildfly-dev] CLI batches in control flow blocks
In-Reply-To: <55E9324F.5060302@redhat.com>
References: <55E86A4D.80809@redhat.com> <55E8C53A.6040207@redhat.com>
	<55E9324F.5060302@redhat.com>
Message-ID: <55E97442.50302@redhat.com>

IMHO.... you cannot use if/then in batches anyhow, e.g:

batch
...
if ...
...
then
...
fi
...
run-batch

fails. So the use of if/then was of very limited use anyhow.

Having multi-level batch would be ideal.
Removing auto-batch from if/then blocks would at least allow batches 
"around" them to work properly which would be a big win anyhow.

just my ?0.02 of course
Tom


On 04/09/15 06:55, Alexey Loubyansky wrote:
> On 09/04/2015 12:10 AM, Brian Stansberry wrote:
>> The risk is this can break existing scripts, which we've sought to
>> avoid. A couple breakage scenarios:
>>
>> 1) Step 1 needs to happen in a batch with Step 2; now it won't so the
>> script breaks.
>> 2) Step 1 works but for some reason Step 2 fails, and now Step 1 isn't
>> rolled back.
>>
>> The first one is more likely, but the second one is a bigger concern, as
>> the user may not be aware Step 1 wasn't rolled back.
>>
>> Do you have any sense of how common either of those scenarios would be?
> Unfortunately, no. I don't get much feedback on this except for created
> issues that I referenced.
> I wouldn't bring it up unless this wasn't a major version release, of
> course.
>
>> Below are bad ideas that I wrote down and then thought better of, but
>> I'll send them in case it sparks a thought.
>>
>> I. Since there is already logic for dropping out of the batch for things
>> like cd, ls, could it be modified as follows?
>>
>> a) Close any current batch and execute that batch.
>> b) Execute the cd, ls, etc
>> c) Proceed, and if the next statement isn't a cd, ls etc, start a new batch.
>>
>> That seems like a better semantic for cd and ls anyway.
> I don't think so. The batch mode is also a composition/editing mode. cd
> and ls are useful when writing commands/operations that should be added
> to the batch. Imagine editing a batch and wishing to cd before entering
> next lines. That won't be possible without explicit holback-batch, cd
> and then batch again. That would be inconvenient.
>
>> With that, reload and shutdown can be treated the same as cd, ls.
> For reload and shutdown that does seem to make sense. So, a possible
> alternative is making them exceptions.
>
>> Why a bad idea? Doing it as I suggest has the same two drawbacks as
>> requiring the user to declare the batch. :( Just perhaps less likely to
>> occur.
>>
>> II. Is an --auto-batch=true|false param to if/else/try/catch/finally
>> possible? Why a bad idea? To solve the breakage problem it would need to
>> be 'true' by default, thus forcing users forever to declare that they
>> want the non-broken mode, *plus* they have to declare the batches.
> As a param to if/else/try/catch/finally this doesn't make sense to me.
> Because then the user could simply explicitly start bodies with batch.
> This kind of argument could make sense as a launching script argument
> for the whole cli session, imo.
>
> Thanks,
> Alexey
>
>>
>> On 9/3/15 10:42 AM, Alexey Loubyansky wrote:
>>> Hello everyone,
>>>
>>> I've been thinking about changing how the bodies of if-else and
>>> try-catch-finally are treated by the CLI.
>>>
>>> Up until now every control flow block (i.e. between if and else, between
>>> else and end-if, etc) was executed as a batch. So, when a block was
>>> selected for the execution, the CLI would enter the batch mode and
>>> proceed adding operations (and commands translated to operations) to it.
>>> If a command can't be translated to an operation, it would be executed
>>> outside the batch immediately (that's done for commands like cd, ls,
>>> etc). After the last line of the body processed, the batch (if not
>>> empty) is executed.
>>>
>>> But this doesn't work when mixing operations with shutdown or reload
>>> commands (they do translate to operations but they have additional logic
>>> related to re-connecting). shutdown/reload will be executed outside the
>>> batch and before the batch is complete.
>>>
>>> Currently open issues for this
>>> https://issues.jboss.org/browse/WFCORE-876
>>> https://issues.jboss.org/browse/WFCORE-533
>>>
>>> So, I think it was a mistake to execute the bodies of control flow
>>> blocks as batches. It would be better leave them as usual sequences of
>>> command lines and if the user wants a batch, he/she could add batch
>>> command explicitly.
>>>
>>> I wanted to ask for opinions. Could we make this change in WildFly 10?
>>>
>>> Thanks,
>>> Alexey
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Tom R. Fonteyne - SSME
Red Hat - UK
EMEA GSS SEG-Middleware


From alexey.loubyansky at redhat.com  Fri Sep  4 07:51:39 2015
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Fri, 04 Sep 2015 13:51:39 +0200
Subject: [wildfly-dev] CLI batches in control flow blocks
In-Reply-To: <55E97442.50302@redhat.com>
References: <55E86A4D.80809@redhat.com> <55E8C53A.6040207@redhat.com>
	<55E9324F.5060302@redhat.com> <55E97442.50302@redhat.com>
Message-ID: <55E985CB.4010703@redhat.com>

Yes, that could be another reason. Thanks.

Although, this is where it gets complicated and confusing.

By multi-level, did you mean nested batches? Like nested transactions?
If so, I don't think we'll go for that. It's just too complicated.

Removing auto-batch from if/else and using them in a batch like you 
described could still be confusing. The batch won't be executed until 
all the lines preceding run-batch are added to the batch. Now we have if 
in the middle. What if the condition depends on the operations between 
batch and if? The evaluation of the if condition w/o executing those 
won't be correct. And we won't be able to predict the effects of the 
operations on the model w/o actually sending them to the controller 
(because unless it's write-attribute, the operations may do whatever).

So, that would be an improvement to be able to use if/else in the batch 
but the condition should not depend on the operations preceding the if.

Thanks,
Alexey

On 09/04/2015 12:36 PM, Tom Fonteyne wrote:
> IMHO.... you cannot use if/then in batches anyhow, e.g:
>
> batch
> ...
> if ...
> ...
> then
> ...
> fi
> ...
> run-batch
>
> fails. So the use of if/then was of very limited use anyhow.
>
> Having multi-level batch would be ideal.
> Removing auto-batch from if/then blocks would at least allow batches
> "around" them to work properly which would be a big win anyhow.
>
> just my ?0.02 of course
> Tom
>
>
> On 04/09/15 06:55, Alexey Loubyansky wrote:
>> On 09/04/2015 12:10 AM, Brian Stansberry wrote:
>>> The risk is this can break existing scripts, which we've sought to
>>> avoid. A couple breakage scenarios:
>>>
>>> 1) Step 1 needs to happen in a batch with Step 2; now it won't so the
>>> script breaks.
>>> 2) Step 1 works but for some reason Step 2 fails, and now Step 1 isn't
>>> rolled back.
>>>
>>> The first one is more likely, but the second one is a bigger concern, as
>>> the user may not be aware Step 1 wasn't rolled back.
>>>
>>> Do you have any sense of how common either of those scenarios would be?
>> Unfortunately, no. I don't get much feedback on this except for created
>> issues that I referenced.
>> I wouldn't bring it up unless this wasn't a major version release, of
>> course.
>>
>>> Below are bad ideas that I wrote down and then thought better of, but
>>> I'll send them in case it sparks a thought.
>>>
>>> I. Since there is already logic for dropping out of the batch for things
>>> like cd, ls, could it be modified as follows?
>>>
>>> a) Close any current batch and execute that batch.
>>> b) Execute the cd, ls, etc
>>> c) Proceed, and if the next statement isn't a cd, ls etc, start a new
>>> batch.
>>>
>>> That seems like a better semantic for cd and ls anyway.
>> I don't think so. The batch mode is also a composition/editing mode. cd
>> and ls are useful when writing commands/operations that should be added
>> to the batch. Imagine editing a batch and wishing to cd before entering
>> next lines. That won't be possible without explicit holback-batch, cd
>> and then batch again. That would be inconvenient.
>>
>>> With that, reload and shutdown can be treated the same as cd, ls.
>> For reload and shutdown that does seem to make sense. So, a possible
>> alternative is making them exceptions.
>>
>>> Why a bad idea? Doing it as I suggest has the same two drawbacks as
>>> requiring the user to declare the batch. :( Just perhaps less likely to
>>> occur.
>>>
>>> II. Is an --auto-batch=true|false param to if/else/try/catch/finally
>>> possible? Why a bad idea? To solve the breakage problem it would need to
>>> be 'true' by default, thus forcing users forever to declare that they
>>> want the non-broken mode, *plus* they have to declare the batches.
>> As a param to if/else/try/catch/finally this doesn't make sense to me.
>> Because then the user could simply explicitly start bodies with batch.
>> This kind of argument could make sense as a launching script argument
>> for the whole cli session, imo.
>>
>> Thanks,
>> Alexey
>>
>>>
>>> On 9/3/15 10:42 AM, Alexey Loubyansky wrote:
>>>> Hello everyone,
>>>>
>>>> I've been thinking about changing how the bodies of if-else and
>>>> try-catch-finally are treated by the CLI.
>>>>
>>>> Up until now every control flow block (i.e. between if and else,
>>>> between
>>>> else and end-if, etc) was executed as a batch. So, when a block was
>>>> selected for the execution, the CLI would enter the batch mode and
>>>> proceed adding operations (and commands translated to operations) to
>>>> it.
>>>> If a command can't be translated to an operation, it would be executed
>>>> outside the batch immediately (that's done for commands like cd, ls,
>>>> etc). After the last line of the body processed, the batch (if not
>>>> empty) is executed.
>>>>
>>>> But this doesn't work when mixing operations with shutdown or reload
>>>> commands (they do translate to operations but they have additional
>>>> logic
>>>> related to re-connecting). shutdown/reload will be executed outside the
>>>> batch and before the batch is complete.
>>>>
>>>> Currently open issues for this
>>>> https://issues.jboss.org/browse/WFCORE-876
>>>> https://issues.jboss.org/browse/WFCORE-533
>>>>
>>>> So, I think it was a mistake to execute the bodies of control flow
>>>> blocks as batches. It would be better leave them as usual sequences of
>>>> command lines and if the user wants a batch, he/she could add batch
>>>> command explicitly.
>>>>
>>>> I wanted to ask for opinions. Could we make this change in WildFly 10?
>>>>
>>>> Thanks,
>>>> Alexey
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From tfonteyn at redhat.com  Fri Sep  4 09:14:32 2015
From: tfonteyn at redhat.com (Tom Fonteyne)
Date: Fri, 4 Sep 2015 14:14:32 +0100
Subject: [wildfly-dev] CLI batches in control flow blocks
In-Reply-To: <55E985CB.4010703@redhat.com>
References: <55E86A4D.80809@redhat.com> <55E8C53A.6040207@redhat.com>
	<55E9324F.5060302@redhat.com> <55E97442.50302@redhat.com>
	<55E985CB.4010703@redhat.com>
Message-ID: <55E99938.7070304@redhat.com>



On 04/09/15 12:51, Alexey Loubyansky wrote:
> Yes, that could be another reason. Thanks.
>
> Although, this is where it gets complicated and confusing.
>
> By multi-level, did you mean nested batches? Like nested transactions?
> If so, I don't think we'll go for that. It's just too complicated.
that's why I say "ideally" :)  But you are almost certainly right on this.
>
> Removing auto-batch from if/else and using them in a batch like you 
> described could still be confusing. The batch won't be executed until 
> all the lines preceding run-batch are added to the batch. Now we have 
> if in the middle. What if the condition depends on the operations 
> between batch and if? The evaluation of the if condition w/o executing 
> those won't be correct. And we won't be able to predict the effects of 
> the operations on the model w/o actually sending them to the 
> controller (because unless it's write-attribute, the operations may do 
> whatever).
yes, it would difficult/confusing as well.

to be fair, anyone asking me about if/then in CLI.... I usually point 
out that if they feel they need things like this, they should use a 
scripting language (or the Java API itself)

>
> So, that would be an improvement to be able to use if/else in the 
> batch but the condition should not depend on the operations preceding 
> the if.
>
> Thanks,
> Alexey
>
> On 09/04/2015 12:36 PM, Tom Fonteyne wrote:
>> IMHO.... you cannot use if/then in batches anyhow, e.g:
>>
>> batch
>> ...
>> if ...
>> ...
>> then
>> ...
>> fi
>> ...
>> run-batch
>>
>> fails. So the use of if/then was of very limited use anyhow.
>>
>> Having multi-level batch would be ideal.
>> Removing auto-batch from if/then blocks would at least allow batches
>> "around" them to work properly which would be a big win anyhow.
>>
>> just my ?0.02 of course
>> Tom
>>
>>
>> On 04/09/15 06:55, Alexey Loubyansky wrote:
>>> On 09/04/2015 12:10 AM, Brian Stansberry wrote:
>>>> The risk is this can break existing scripts, which we've sought to
>>>> avoid. A couple breakage scenarios:
>>>>
>>>> 1) Step 1 needs to happen in a batch with Step 2; now it won't so the
>>>> script breaks.
>>>> 2) Step 1 works but for some reason Step 2 fails, and now Step 1 isn't
>>>> rolled back.
>>>>
>>>> The first one is more likely, but the second one is a bigger 
>>>> concern, as
>>>> the user may not be aware Step 1 wasn't rolled back.
>>>>
>>>> Do you have any sense of how common either of those scenarios would 
>>>> be?
>>> Unfortunately, no. I don't get much feedback on this except for created
>>> issues that I referenced.
>>> I wouldn't bring it up unless this wasn't a major version release, of
>>> course.
>>>
>>>> Below are bad ideas that I wrote down and then thought better of, but
>>>> I'll send them in case it sparks a thought.
>>>>
>>>> I. Since there is already logic for dropping out of the batch for 
>>>> things
>>>> like cd, ls, could it be modified as follows?
>>>>
>>>> a) Close any current batch and execute that batch.
>>>> b) Execute the cd, ls, etc
>>>> c) Proceed, and if the next statement isn't a cd, ls etc, start a new
>>>> batch.
>>>>
>>>> That seems like a better semantic for cd and ls anyway.
>>> I don't think so. The batch mode is also a composition/editing mode. cd
>>> and ls are useful when writing commands/operations that should be added
>>> to the batch. Imagine editing a batch and wishing to cd before entering
>>> next lines. That won't be possible without explicit holback-batch, cd
>>> and then batch again. That would be inconvenient.
>>>
>>>> With that, reload and shutdown can be treated the same as cd, ls.
>>> For reload and shutdown that does seem to make sense. So, a possible
>>> alternative is making them exceptions.
>>>
>>>> Why a bad idea? Doing it as I suggest has the same two drawbacks as
>>>> requiring the user to declare the batch. :( Just perhaps less 
>>>> likely to
>>>> occur.
>>>>
>>>> II. Is an --auto-batch=true|false param to if/else/try/catch/finally
>>>> possible? Why a bad idea? To solve the breakage problem it would 
>>>> need to
>>>> be 'true' by default, thus forcing users forever to declare that they
>>>> want the non-broken mode, *plus* they have to declare the batches.
>>> As a param to if/else/try/catch/finally this doesn't make sense to me.
>>> Because then the user could simply explicitly start bodies with batch.
>>> This kind of argument could make sense as a launching script argument
>>> for the whole cli session, imo.
>>>
>>> Thanks,
>>> Alexey
>>>
>>>>
>>>> On 9/3/15 10:42 AM, Alexey Loubyansky wrote:
>>>>> Hello everyone,
>>>>>
>>>>> I've been thinking about changing how the bodies of if-else and
>>>>> try-catch-finally are treated by the CLI.
>>>>>
>>>>> Up until now every control flow block (i.e. between if and else,
>>>>> between
>>>>> else and end-if, etc) was executed as a batch. So, when a block was
>>>>> selected for the execution, the CLI would enter the batch mode and
>>>>> proceed adding operations (and commands translated to operations) to
>>>>> it.
>>>>> If a command can't be translated to an operation, it would be 
>>>>> executed
>>>>> outside the batch immediately (that's done for commands like cd, ls,
>>>>> etc). After the last line of the body processed, the batch (if not
>>>>> empty) is executed.
>>>>>
>>>>> But this doesn't work when mixing operations with shutdown or reload
>>>>> commands (they do translate to operations but they have additional
>>>>> logic
>>>>> related to re-connecting). shutdown/reload will be executed 
>>>>> outside the
>>>>> batch and before the batch is complete.
>>>>>
>>>>> Currently open issues for this
>>>>> https://issues.jboss.org/browse/WFCORE-876
>>>>> https://issues.jboss.org/browse/WFCORE-533
>>>>>
>>>>> So, I think it was a mistake to execute the bodies of control flow
>>>>> blocks as batches. It would be better leave them as usual 
>>>>> sequences of
>>>>> command lines and if the user wants a batch, he/she could add batch
>>>>> command explicitly.
>>>>>
>>>>> I wanted to ask for opinions. Could we make this change in WildFly 
>>>>> 10?
>>>>>
>>>>> Thanks,
>>>>> Alexey
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>

-- 
Tom R. Fonteyne - SSME
Red Hat - UK
EMEA GSS SEG-Middleware


From ewertz at redhat.com  Fri Sep  4 10:04:31 2015
From: ewertz at redhat.com (Edward Wertz)
Date: Fri, 4 Sep 2015 10:04:31 -0400 (EDT)
Subject: [wildfly-dev] CLI Non-Interactive Output Changes
In-Reply-To: <29623475.88.1441373438944.JavaMail.joe@localhost.localdomain>
Message-ID: <17959908.98.1441375466638.JavaMail.joe@localhost.localdomain>

Hello All,

I've been doing some work on the non-interactive mode of the CLI, when using --file or --commands, and since the current version of the work changes the output slightly I'd like to get some opinions on it. The changes are necessary in order to pass the non-interactive commands through the AESH console system, which enables additional functionality like the history file and 'alias' command. If not done, the non-interactive mode functionality won't behave the same as the interactive mode. Commands handled by AESH like 'alias' will be missing entirely, and non-interactive commands won't show up in the cli history file. If AESH is expanded further in the future, more commands will be inaccessible in non-interactive mode.

The existing output for this mode only includes the command output. It doesn't include the commands entered, or the interactive command prompts like '[disconnected /]'. Exampled like so:

[joe at localhost bin]$ ./jboss-cli.sh --commands=version,connect,version,"echo tim"
JBoss Admin Command-line Interface
JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
JBoss AS release: <connect to the controller and re-run the version command to see the release info>
JAVA_HOME: null
java.version: 1.8.0_45
java.vm.vendor: Oracle Corporation
java.vm.version: 25.45-b02
os.name: Linux
os.version: 4.1.6-200.fc22.x86_64
JBoss Admin Command-line Interface
JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
JAVA_HOME: null
java.version: 1.8.0_45
java.vm.vendor: Oracle Corporation
java.vm.version: 25.45-b02
os.name: Linux
os.version: 4.1.6-200.fc22.x86_64
tim

The new output, as it exists right now, contains the command and it's output. Like so:

[joe at localhost Changed Output]$ ./wildfly-cli-2.0.0.CR1-SNAPSHOT-client-new.jar --commands=version,connect,version,"echo tim"
WARN: can't find jboss-cli.xml. Using default configuration values.
version
JBoss Admin Command-line Interface
JBOSS_HOME: null
JBoss AS release: <connect to the controller and re-run the version command to see the release info>
JAVA_HOME: null
java.version: 1.8.0_45
java.vm.vendor: Oracle Corporation
java.vm.version: 25.45-b02
os.name: Linux
os.version: 4.1.6-200.fc22.x86_64
connect
Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions.
version
JBoss Admin Command-line Interface
JBOSS_HOME: null
JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
JAVA_HOME: null
java.version: 1.8.0_45
java.vm.vendor: Oracle Corporation
java.vm.version: 25.45-b02
os.name: Linux
os.version: 4.1.6-200.fc22.x86_64
echo tim
tim

'version', 'connect', 'version', and 'echo tim' lines are now in the output, along with some information messages. I think this makes the output more useful, since the user can see which command was entered before the output or possible error occurs. It shouldn't have an impact on existing scripts, because the output still contains the expected output from any command and still ends with the last command output, so if someone is doing string analysis I wouldn't expect it to fail.

I'd actually prefer to extend this change and add the command prompts into the output as well. Which would look like this:

[joe at localhost bin]$ ./jboss-cli.sh --commands=version,"alias v=version",connect,v,"echo tim"
[disconnected /] version
JBoss Admin Command-line Interface
JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
JBoss AS release: <connect to the controller and re-run the version command to see the release info>
JAVA_HOME: null
java.version: 1.8.0_45
java.vm.vendor: Oracle Corporation
java.vm.version: 25.45-b02
os.name: Linux
os.version: 4.1.6-200.fc22.x86_64
[disconnected /] alias v=version
[disconnected /] connect
[standalone at localhost:9990 /] v
JBoss Admin Command-line Interface
JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
JAVA_HOME: null
java.version: 1.8.0_45
java.vm.vendor: Oracle Corporation
java.vm.version: 25.45-b02
os.name: Linux
os.version: 4.1.6-200.fc22.x86_64
[standalone at localhost:9990 /] echo tim
tim
[standalone at localhost:9990 /] 

This, to me, adds more information to the output making it more useful. I like the idea of the non-interactive mode imitating the interactive mode closely and essentially pretending to be a user, and this output is almost identical to a user entering these commands one at a time. It does, however, modify the end of the output stream which could break analysis scripts. A contains would be fine, but an ends-with would be broken because of the last prompt.

Normal interactive mode output is unchanged. This will only effect '--file=' and '--commands=' output.

Thoughts?

Joe Wertz

From brian.stansberry at redhat.com  Fri Sep  4 10:27:06 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 4 Sep 2015 09:27:06 -0500
Subject: [wildfly-dev] CLI batches in control flow blocks
In-Reply-To: <55E9324F.5060302@redhat.com>
References: <55E86A4D.80809@redhat.com> <55E8C53A.6040207@redhat.com>
	<55E9324F.5060302@redhat.com>
Message-ID: <55E9AA3A.50603@redhat.com>

On 9/4/15 12:55 AM, Alexey Loubyansky wrote:
> On 09/04/2015 12:10 AM, Brian Stansberry wrote:
>> The risk is this can break existing scripts, which we've sought to
>> avoid. A couple breakage scenarios:
>>
>> 1) Step 1 needs to happen in a batch with Step 2; now it won't so the
>> script breaks.
>> 2) Step 1 works but for some reason Step 2 fails, and now Step 1 isn't
>> rolled back.
>>
>> The first one is more likely, but the second one is a bigger concern, as
>> the user may not be aware Step 1 wasn't rolled back.
>>
>> Do you have any sense of how common either of those scenarios would be?
>
> Unfortunately, no. I don't get much feedback on this except for created
> issues that I referenced.
> I wouldn't bring it up unless this wasn't a major version release, of
> course.
>

Yes, it's now or not for a long time.

>> Below are bad ideas that I wrote down and then thought better of, but
>> I'll send them in case it sparks a thought.
>>
>> I. Since there is already logic for dropping out of the batch for things
>> like cd, ls, could it be modified as follows?
>>
>> a) Close any current batch and execute that batch.
>> b) Execute the cd, ls, etc
>> c) Proceed, and if the next statement isn't a cd, ls etc, start a new batch.
>>
>> That seems like a better semantic for cd and ls anyway.
>
> I don't think so. The batch mode is also a composition/editing mode. cd
> and ls are useful when writing commands/operations that should be added
> to the batch. Imagine editing a batch and wishing to cd before entering
> next lines. That won't be possible without explicit holback-batch, cd
> and then batch again. That would be inconvenient.
>

Thanks; that's a very good point. Yesterday, I was having a hard time 
seeing the point of ls inside an if/else; now I get it. :)

>> With that, reload and shutdown can be treated the same as cd, ls.
>
> For reload and shutdown that does seem to make sense. So, a possible
> alternative is making them exceptions.
>

I said yesterday (below) that this was a bad idea because it can still 
break scripts or prevent rollback, same as your proposal. But I think in 
practice this wouldn't be a real drawback, since AIUI the bugs mean any 
existing script with reload/shutdown in the middle of a bunch of other 
ops would be broken anyway. Right?

>> Why a bad idea? Doing it as I suggest has the same two drawbacks as
>> requiring the user to declare the batch. :( Just perhaps less likely to
>> occur.
>>
>> II. Is an --auto-batch=true|false param to if/else/try/catch/finally
>> possible? Why a bad idea? To solve the breakage problem it would need to
>> be 'true' by default, thus forcing users forever to declare that they
>> want the non-broken mode, *plus* they have to declare the batches.
>
> As a param to if/else/try/catch/finally this doesn't make sense to me.
> Because then the user could simply explicitly start bodies with batch.
> This kind of argument could make sense as a launching script argument
> for the whole cli session, imo.
>

The drawbacks are the same though. To avoid breaking old scripts the 
default behavior would have to be the old behavior, and then the people 
wanting the new, correct behavior would have to jump through strange hoops.

> Thanks,
> Alexey
>
>>
>>
>> On 9/3/15 10:42 AM, Alexey Loubyansky wrote:
>>> Hello everyone,
>>>
>>> I've been thinking about changing how the bodies of if-else and
>>> try-catch-finally are treated by the CLI.
>>>
>>> Up until now every control flow block (i.e. between if and else, between
>>> else and end-if, etc) was executed as a batch. So, when a block was
>>> selected for the execution, the CLI would enter the batch mode and
>>> proceed adding operations (and commands translated to operations) to it.
>>> If a command can't be translated to an operation, it would be executed
>>> outside the batch immediately (that's done for commands like cd, ls,
>>> etc). After the last line of the body processed, the batch (if not
>>> empty) is executed.
>>>
>>> But this doesn't work when mixing operations with shutdown or reload
>>> commands (they do translate to operations but they have additional logic
>>> related to re-connecting). shutdown/reload will be executed outside the
>>> batch and before the batch is complete.
>>>
>>> Currently open issues for this
>>> https://issues.jboss.org/browse/WFCORE-876
>>> https://issues.jboss.org/browse/WFCORE-533
>>>
>>> So, I think it was a mistake to execute the bodies of control flow
>>> blocks as batches. It would be better leave them as usual sequences of
>>> command lines and if the user wants a batch, he/she could add batch
>>> command explicitly.
>>>
>>> I wanted to ask for opinions. Could we make this change in WildFly 10?
>>>
>>> Thanks,
>>> Alexey
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From brian.stansberry at redhat.com  Fri Sep  4 10:46:45 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 4 Sep 2015 09:46:45 -0500
Subject: [wildfly-dev] CLI Non-Interactive Output Changes
In-Reply-To: <17959908.98.1441375466638.JavaMail.joe@localhost.localdomain>
References: <17959908.98.1441375466638.JavaMail.joe@localhost.localdomain>
Message-ID: <55E9AED5.2050509@redhat.com>

How hard would it be to get rid of that last line? I much prefer the 
output with the prompt, but I think the last line issue is a valid concern.

Does this have any impact on embedded uses of the CLI?

Most importantly, can it be turned off?

I ask, because I'm concerned about things like this:

$ bin/jboss-cli.sh 
--commands=connect,/server-group=main-server-group:read-resource
{
     "outcome" => "success",
     "result" => {
         "management-subsystem-endpoint" => false,
         "profile" => "full",
         "socket-binding-default-interface" => undefined,
         "socket-binding-group" => "full-sockets",
         "socket-binding-port-offset" => 0,
         "deployment" => undefined,
         "deployment-overlay" => undefined,
         "jvm" => {"default" => undefined},
         "system-property" => undefined
     }
}

That response can be fairly simply parsed and analyzed, since it's the 
direct representation of a ModelNode. Adding a line of text breaks that.

Perhaps most use cases that would be doing that kind of parsing/analysis 
would be embedding the CLI in a java app that does that work, since then 
you can easily use ModelNode itself. But not necessarily all. Our low 
level op responses have a well known format and the parsing isn't rocket 
science.


On 9/4/15 9:04 AM, Edward Wertz wrote:
> Hello All,
>
> I've been doing some work on the non-interactive mode of the CLI, when using --file or --commands, and since the current version of the work changes the output slightly I'd like to get some opinions on it. The changes are necessary in order to pass the non-interactive commands through the AESH console system, which enables additional functionality like the history file and 'alias' command. If not done, the non-interactive mode functionality won't behave the same as the interactive mode. Commands handled by AESH like 'alias' will be missing entirely, and non-interactive commands won't show up in the cli history file. If AESH is expanded further in the future, more commands will be inaccessible in non-interactive mode.
>
> The existing output for this mode only includes the command output. It doesn't include the commands entered, or the interactive command prompts like '[disconnected /]'. Exampled like so:
>
> [joe at localhost bin]$ ./jboss-cli.sh --commands=version,connect,version,"echo tim"
> JBoss Admin Command-line Interface
> JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
> JBoss AS release: <connect to the controller and re-run the version command to see the release info>
> JAVA_HOME: null
> java.version: 1.8.0_45
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.45-b02
> os.name: Linux
> os.version: 4.1.6-200.fc22.x86_64
> JBoss Admin Command-line Interface
> JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
> JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
> JAVA_HOME: null
> java.version: 1.8.0_45
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.45-b02
> os.name: Linux
> os.version: 4.1.6-200.fc22.x86_64
> tim
>
> The new output, as it exists right now, contains the command and it's output. Like so:
>
> [joe at localhost Changed Output]$ ./wildfly-cli-2.0.0.CR1-SNAPSHOT-client-new.jar --commands=version,connect,version,"echo tim"
> WARN: can't find jboss-cli.xml. Using default configuration values.
> version
> JBoss Admin Command-line Interface
> JBOSS_HOME: null
> JBoss AS release: <connect to the controller and re-run the version command to see the release info>
> JAVA_HOME: null
> java.version: 1.8.0_45
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.45-b02
> os.name: Linux
> os.version: 4.1.6-200.fc22.x86_64
> connect
> Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions.
> version
> JBoss Admin Command-line Interface
> JBOSS_HOME: null
> JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
> JAVA_HOME: null
> java.version: 1.8.0_45
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.45-b02
> os.name: Linux
> os.version: 4.1.6-200.fc22.x86_64
> echo tim
> tim
>
> 'version', 'connect', 'version', and 'echo tim' lines are now in the output, along with some information messages. I think this makes the output more useful, since the user can see which command was entered before the output or possible error occurs. It shouldn't have an impact on existing scripts, because the output still contains the expected output from any command and still ends with the last command output, so if someone is doing string analysis I wouldn't expect it to fail.
>
> I'd actually prefer to extend this change and add the command prompts into the output as well. Which would look like this:
>
> [joe at localhost bin]$ ./jboss-cli.sh --commands=version,"alias v=version",connect,v,"echo tim"
> [disconnected /] version
> JBoss Admin Command-line Interface
> JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
> JBoss AS release: <connect to the controller and re-run the version command to see the release info>
> JAVA_HOME: null
> java.version: 1.8.0_45
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.45-b02
> os.name: Linux
> os.version: 4.1.6-200.fc22.x86_64
> [disconnected /] alias v=version
> [disconnected /] connect
> [standalone at localhost:9990 /] v
> JBoss Admin Command-line Interface
> JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
> JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
> JAVA_HOME: null
> java.version: 1.8.0_45
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.45-b02
> os.name: Linux
> os.version: 4.1.6-200.fc22.x86_64
> [standalone at localhost:9990 /] echo tim
> tim
> [standalone at localhost:9990 /]
>
> This, to me, adds more information to the output making it more useful. I like the idea of the non-interactive mode imitating the interactive mode closely and essentially pretending to be a user, and this output is almost identical to a user entering these commands one at a time. It does, however, modify the end of the output stream which could break analysis scripts. A contains would be fine, but an ends-with would be broken because of the last prompt.
>
> Normal interactive mode output is unchanged. This will only effect '--file=' and '--commands=' output.
>
> Thoughts?
>
> Joe Wertz
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From alexey.loubyansky at redhat.com  Fri Sep  4 11:37:16 2015
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Fri, 04 Sep 2015 17:37:16 +0200
Subject: [wildfly-dev] CLI Non-Interactive Output Changes
In-Reply-To: <55E9AED5.2050509@redhat.com>
References: <17959908.98.1441375466638.JavaMail.joe@localhost.localdomain>
	<55E9AED5.2050509@redhat.com>
Message-ID: <55E9BAAC.7030300@redhat.com>

On 09/04/2015 04:46 PM, Brian Stansberry wrote:
> How hard would it be to get rid of that last line? I much prefer the
> output with the prompt, but I think the last line issue is a valid concern.
>
> Does this have any impact on embedded uses of the CLI?
>
> Most importantly, can it be turned off?
>
> I ask, because I'm concerned about things like this:
>
> $ bin/jboss-cli.sh
> --commands=connect,/server-group=main-server-group:read-resource
> {
>       "outcome" => "success",
>       "result" => {
>           "management-subsystem-endpoint" => false,
>           "profile" => "full",
>           "socket-binding-default-interface" => undefined,
>           "socket-binding-group" => "full-sockets",
>           "socket-binding-port-offset" => 0,
>           "deployment" => undefined,
>           "deployment-overlay" => undefined,
>           "jvm" => {"default" => undefined},
>           "system-property" => undefined
>       }
> }
>
> That response can be fairly simply parsed and analyzed, since it's the
> direct representation of a ModelNode. Adding a line of text breaks that.

I had the same thought.
When multiple command lines passed into non-interactive mode, the 
proposed output does look easier to understand and navigate. In case of 
a single line, it looks even a bit strange to me.

Thanks,
Alexey

> Perhaps most use cases that would be doing that kind of parsing/analysis
> would be embedding the CLI in a java app that does that work, since then
> you can easily use ModelNode itself. But not necessarily all. Our low
> level op responses have a well known format and the parsing isn't rocket
> science.
>
>
> On 9/4/15 9:04 AM, Edward Wertz wrote:
>> Hello All,
>>
>> I've been doing some work on the non-interactive mode of the CLI, when using --file or --commands, and since the current version of the work changes the output slightly I'd like to get some opinions on it. The changes are necessary in order to pass the non-interactive commands through the AESH console system, which enables additional functionality like the history file and 'alias' command. If not done, the non-interactive mode functionality won't behave the same as the interactive mode. Commands handled by AESH like 'alias' will be missing entirely, and non-interactive commands won't show up in the cli history file. If AESH is expanded further in the future, more commands will be inaccessible in non-interactive mode.
>>
>> The existing output for this mode only includes the command output. It doesn't include the commands entered, or the interactive command prompts like '[disconnected /]'. Exampled like so:
>>
>> [joe at localhost bin]$ ./jboss-cli.sh --commands=version,connect,version,"echo tim"
>> JBoss Admin Command-line Interface
>> JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
>> JBoss AS release: <connect to the controller and re-run the version command to see the release info>
>> JAVA_HOME: null
>> java.version: 1.8.0_45
>> java.vm.vendor: Oracle Corporation
>> java.vm.version: 25.45-b02
>> os.name: Linux
>> os.version: 4.1.6-200.fc22.x86_64
>> JBoss Admin Command-line Interface
>> JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
>> JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
>> JAVA_HOME: null
>> java.version: 1.8.0_45
>> java.vm.vendor: Oracle Corporation
>> java.vm.version: 25.45-b02
>> os.name: Linux
>> os.version: 4.1.6-200.fc22.x86_64
>> tim
>>
>> The new output, as it exists right now, contains the command and it's output. Like so:
>>
>> [joe at localhost Changed Output]$ ./wildfly-cli-2.0.0.CR1-SNAPSHOT-client-new.jar --commands=version,connect,version,"echo tim"
>> WARN: can't find jboss-cli.xml. Using default configuration values.
>> version
>> JBoss Admin Command-line Interface
>> JBOSS_HOME: null
>> JBoss AS release: <connect to the controller and re-run the version command to see the release info>
>> JAVA_HOME: null
>> java.version: 1.8.0_45
>> java.vm.vendor: Oracle Corporation
>> java.vm.version: 25.45-b02
>> os.name: Linux
>> os.version: 4.1.6-200.fc22.x86_64
>> connect
>> Warning! The CLI is running in a non-modular environment and cannot load commands from management extensions.
>> version
>> JBoss Admin Command-line Interface
>> JBOSS_HOME: null
>> JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
>> JAVA_HOME: null
>> java.version: 1.8.0_45
>> java.vm.vendor: Oracle Corporation
>> java.vm.version: 25.45-b02
>> os.name: Linux
>> os.version: 4.1.6-200.fc22.x86_64
>> echo tim
>> tim
>>
>> 'version', 'connect', 'version', and 'echo tim' lines are now in the output, along with some information messages. I think this makes the output more useful, since the user can see which command was entered before the output or possible error occurs. It shouldn't have an impact on existing scripts, because the output still contains the expected output from any command and still ends with the last command output, so if someone is doing string analysis I wouldn't expect it to fail.
>>
>> I'd actually prefer to extend this change and add the command prompts into the output as well. Which would look like this:
>>
>> [joe at localhost bin]$ ./jboss-cli.sh --commands=version,"alias v=version",connect,v,"echo tim"
>> [disconnected /] version
>> JBoss Admin Command-line Interface
>> JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
>> JBoss AS release: <connect to the controller and re-run the version command to see the release info>
>> JAVA_HOME: null
>> java.version: 1.8.0_45
>> java.vm.vendor: Oracle Corporation
>> java.vm.version: 25.45-b02
>> os.name: Linux
>> os.version: 4.1.6-200.fc22.x86_64
>> [disconnected /] alias v=version
>> [disconnected /] connect
>> [standalone at localhost:9990 /] v
>> JBoss Admin Command-line Interface
>> JBOSS_HOME: /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
>> JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
>> JAVA_HOME: null
>> java.version: 1.8.0_45
>> java.vm.vendor: Oracle Corporation
>> java.vm.version: 25.45-b02
>> os.name: Linux
>> os.version: 4.1.6-200.fc22.x86_64
>> [standalone at localhost:9990 /] echo tim
>> tim
>> [standalone at localhost:9990 /]
>>
>> This, to me, adds more information to the output making it more useful. I like the idea of the non-interactive mode imitating the interactive mode closely and essentially pretending to be a user, and this output is almost identical to a user entering these commands one at a time. It does, however, modify the end of the output stream which could break analysis scripts. A contains would be fine, but an ends-with would be broken because of the last prompt.
>>
>> Normal interactive mode output is unchanged. This will only effect '--file=' and '--commands=' output.
>>
>> Thoughts?
>>
>> Joe Wertz
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>

From alexey.loubyansky at redhat.com  Fri Sep  4 11:44:15 2015
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Fri, 04 Sep 2015 17:44:15 +0200
Subject: [wildfly-dev] CLI batches in control flow blocks
In-Reply-To: <55E9AA3A.50603@redhat.com>
References: <55E86A4D.80809@redhat.com>
	<55E8C53A.6040207@redhat.com>	<55E9324F.5060302@redhat.com>
	<55E9AA3A.50603@redhat.com>
Message-ID: <55E9BC4F.6090206@redhat.com>

On 09/04/2015 04:27 PM, Brian Stansberry wrote:
> On 9/4/15 12:55 AM, Alexey Loubyansky wrote:
>> On 09/04/2015 12:10 AM, Brian Stansberry wrote:

-- skip --

>>> Below are bad ideas that I wrote down and then thought better of, but
>>> I'll send them in case it sparks a thought.
>>>
>>> I. Since there is already logic for dropping out of the batch for things
>>> like cd, ls, could it be modified as follows?
>>>
>>> a) Close any current batch and execute that batch.
>>> b) Execute the cd, ls, etc
>>> c) Proceed, and if the next statement isn't a cd, ls etc, start a new batch.
>>>
>>> That seems like a better semantic for cd and ls anyway.
>>
>> I don't think so. The batch mode is also a composition/editing mode. cd
>> and ls are useful when writing commands/operations that should be added
>> to the batch. Imagine editing a batch and wishing to cd before entering
>> next lines. That won't be possible without explicit holback-batch, cd
>> and then batch again. That would be inconvenient.
>>
>
> Thanks; that's a very good point. Yesterday, I was having a hard time
> seeing the point of ls inside an if/else; now I get it. :)
>
>>> With that, reload and shutdown can be treated the same as cd, ls.
>>
>> For reload and shutdown that does seem to make sense. So, a possible
>> alternative is making them exceptions.
>>
>
> I said yesterday (below) that this was a bad idea because it can still
> break scripts or prevent rollback, same as your proposal. But I think in
> practice this wouldn't be a real drawback, since AIUI the bugs mean any
> existing script with reload/shutdown in the middle of a bunch of other
> ops would be broken anyway. Right?

:reload or :shutdown don't make any sense in the middle of a composite 
operation. If they make sense in a batch, they should be last. Even 
then, does it make sense to include them into a composite operation?

Thanks,
Alexey

From brian.stansberry at redhat.com  Fri Sep  4 12:02:35 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 4 Sep 2015 11:02:35 -0500
Subject: [wildfly-dev] CLI batches in control flow blocks
In-Reply-To: <55E9BC4F.6090206@redhat.com>
References: <55E86A4D.80809@redhat.com> <55E8C53A.6040207@redhat.com>
	<55E9324F.5060302@redhat.com> <55E9AA3A.50603@redhat.com>
	<55E9BC4F.6090206@redhat.com>
Message-ID: <55E9C09B.6040803@redhat.com>

On 9/4/15 10:44 AM, Alexey Loubyansky wrote:
> On 09/04/2015 04:27 PM, Brian Stansberry wrote:
>> On 9/4/15 12:55 AM, Alexey Loubyansky wrote:
>>> On 09/04/2015 12:10 AM, Brian Stansberry wrote:
>
> -- skip --
>
>>>> Below are bad ideas that I wrote down and then thought better of, but
>>>> I'll send them in case it sparks a thought.
>>>>
>>>> I. Since there is already logic for dropping out of the batch for things
>>>> like cd, ls, could it be modified as follows?
>>>>
>>>> a) Close any current batch and execute that batch.
>>>> b) Execute the cd, ls, etc
>>>> c) Proceed, and if the next statement isn't a cd, ls etc, start a new batch.
>>>>
>>>> That seems like a better semantic for cd and ls anyway.
>>>
>>> I don't think so. The batch mode is also a composition/editing mode. cd
>>> and ls are useful when writing commands/operations that should be added
>>> to the batch. Imagine editing a batch and wishing to cd before entering
>>> next lines. That won't be possible without explicit holback-batch, cd
>>> and then batch again. That would be inconvenient.
>>>
>>
>> Thanks; that's a very good point. Yesterday, I was having a hard time
>> seeing the point of ls inside an if/else; now I get it. :)
>>
>>>> With that, reload and shutdown can be treated the same as cd, ls.
>>>
>>> For reload and shutdown that does seem to make sense. So, a possible
>>> alternative is making them exceptions.
>>>
>>
>> I said yesterday (below) that this was a bad idea because it can still
>> break scripts or prevent rollback, same as your proposal. But I think in
>> practice this wouldn't be a real drawback, since AIUI the bugs mean any
>> existing script with reload/shutdown in the middle of a bunch of other
>> ops would be broken anyway. Right?
>
> :reload or :shutdown don't make any sense in the middle of a composite
> operation.

Agreed.

> If they make sense in a batch, they should be last. Even
> then, does it make sense to include them into a composite operation?
>

In a CLI batch, the benefit of including them last is the exclusive 
write lock acquired by the previous steps is held until the reload is 
initiated. If it's a separate step another change from a different 
client can sneak in between.

In a non-CLI composite there's also a minor advantage in that the params 
to :reload/:shutdown will be validated inside the composite and if they 
are invalid this will roll back the composite. But in a CLI batch the 
CLI isn't going to send invalid params from its high level commands.

-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From ewertz at redhat.com  Fri Sep  4 14:20:18 2015
From: ewertz at redhat.com (Edward Wertz)
Date: Fri, 4 Sep 2015 14:20:18 -0400 (EDT)
Subject: [wildfly-dev] CLI Non-Interactive Output Changes
In-Reply-To: <55E9BAAC.7030300@redhat.com>
References: <17959908.98.1441375466638.JavaMail.joe@localhost.localdomain>
	<55E9AED5.2050509@redhat.com> <55E9BAAC.7030300@redhat.com>
Message-ID: <8977586.130.1441390811617.JavaMail.joe@localhost.localdomain>



----- Original Message -----
> From: "Alexey Loubyansky" <alexey.loubyansky at redhat.com>
> To: wildfly-dev at lists.jboss.org
> Sent: Friday, September 4, 2015 11:37:16 PM
> Subject: Re: [wildfly-dev] CLI Non-Interactive Output Changes
> 
> On 09/04/2015 04:46 PM, Brian Stansberry wrote:
> > How hard would it be to get rid of that last line? I much prefer
> > the
> > output with the prompt, but I think the last line issue is a valid
> > concern.
> >
> > Does this have any impact on embedded uses of the CLI?

No. The existing 'handle(line)' API method that a java app would be using is unchanged. The new functionality adds an API method, 'pushToInput(line)', and handle the non-interactive mode now.

> >
> > Most importantly, can it be turned off?
> >
> > I ask, because I'm concerned about things like this:
> >
> > $ bin/jboss-cli.sh
> > --commands=connect,/server-group=main-server-group:read-resource
> > {
> >       "outcome" => "success",
> >       "result" => {
> >           "management-subsystem-endpoint" => false,
> >           "profile" => "full",
> >           "socket-binding-default-interface" => undefined,
> >           "socket-binding-group" => "full-sockets",
> >           "socket-binding-port-offset" => 0,
> >           "deployment" => undefined,
> >           "deployment-overlay" => undefined,
> >           "jvm" => {"default" => undefined},
> >           "system-property" => undefined
> >       }
> > }
> >
> > That response can be fairly simply parsed and analyzed, since it's
> > the
> > direct representation of a ModelNode. Adding a line of text breaks
> > that.
> 
> I had the same thought.
> When multiple command lines passed into non-interactive mode, the
> proposed output does look easier to understand and navigate. In case
> of
> a single line, it looks even a bit strange to me.
> 
> Thanks,
> Alexey
> > Perhaps most use cases that would be doing that kind of
> > parsing/analysis
> > would be embedding the CLI in a java app that does that work, since
> > then
> > you can easily use ModelNode itself. But not necessarily all. Our
> > low
> > level op responses have a well known format and the parsing isn't
> > rocket
> > science.
> >

I can remove the last line, that output would look like this:

[joe at localhost bin]$ ./jboss-cli.sh --commands=connect,/server-group=main-server-group:read-resource
[disconnected /] connect
[domain at localhost:9990 /] /server-group=main-server-group:read-resource
{
    "outcome" => "success",
    "result" => {
        "management-subsystem-endpoint" => false,
        "profile" => "default",
        "socket-binding-default-interface" => undefined,
        "socket-binding-group" => "standard-sockets",
        "socket-binding-port-offset" => 0,
        "deployment" => undefined,
        "deployment-overlay" => undefined,
        "jvm" => {"default" => undefined},
        "system-property" => undefined
    }
}

I can cobble together existing options, remove the prompt and mask the input, which would look like this:

[joe at localhost bin]$ ./jboss-cli.sh --commands=connect,/server-group=main-server-group:read-resource


{
    "outcome" => "success",
    "result" => {
        "management-subsystem-endpoint" => false,
        "profile" => "default",
        "socket-binding-default-interface" => undefined,
        "socket-binding-group" => "standard-sockets",
        "socket-binding-port-offset" => 0,
        "deployment" => undefined,
        "deployment-overlay" => undefined,
        "jvm" => {"default" => undefined},
        "system-property" => undefined
    }
}

Which is very close to the existing output, but includes a newline for each command that gets processed. This could be enabled with a new argument, '--only-output' or something, that's only applicable to non-interactive mode.

In order to remove the newlines, I'd have to make AESH changes to not echo input back to the output stream. I'm not sure how easy that is to do yet, but I haven't found a quick solution that would make sense. It's difficult to predict someone will want to use your UI project as something other than a UI, which would always want to echo input this way, so this might require a redesign of the input processing to create a comprehensive way to handle it.

-- Joe

> >
> > On 9/4/15 9:04 AM, Edward Wertz wrote:
> >> Hello All,
> >>
> >> I've been doing some work on the non-interactive mode of the CLI,
> >> when using --file or --commands, and since the current version of
> >> the work changes the output slightly I'd like to get some
> >> opinions on it. The changes are necessary in order to pass the
> >> non-interactive commands through the AESH console system, which
> >> enables additional functionality like the history file and
> >> 'alias' command. If not done, the non-interactive mode
> >> functionality won't behave the same as the interactive mode.
> >> Commands handled by AESH like 'alias' will be missing entirely,
> >> and non-interactive commands won't show up in the cli history
> >> file. If AESH is expanded further in the future, more commands
> >> will be inaccessible in non-interactive mode.
> >>
> >> The existing output for this mode only includes the command
> >> output. It doesn't include the commands entered, or the
> >> interactive command prompts like '[disconnected /]'. Exampled
> >> like so:
> >>
> >> [joe at localhost bin]$ ./jboss-cli.sh
> >> --commands=version,connect,version,"echo tim"
> >> JBoss Admin Command-line Interface
> >> JBOSS_HOME:
> >> /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
> >> JBoss AS release: <connect to the controller and re-run the
> >> version command to see the release info>
> >> JAVA_HOME: null
> >> java.version: 1.8.0_45
> >> java.vm.vendor: Oracle Corporation
> >> java.vm.version: 25.45-b02
> >> os.name: Linux
> >> os.version: 4.1.6-200.fc22.x86_64
> >> JBoss Admin Command-line Interface
> >> JBOSS_HOME:
> >> /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
> >> JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
> >> JAVA_HOME: null
> >> java.version: 1.8.0_45
> >> java.vm.vendor: Oracle Corporation
> >> java.vm.version: 25.45-b02
> >> os.name: Linux
> >> os.version: 4.1.6-200.fc22.x86_64
> >> tim
> >>
> >> The new output, as it exists right now, contains the command and
> >> it's output. Like so:
> >>
> >> [joe at localhost Changed Output]$
> >> ./wildfly-cli-2.0.0.CR1-SNAPSHOT-client-new.jar
> >> --commands=version,connect,version,"echo tim"
> >> WARN: can't find jboss-cli.xml. Using default configuration
> >> values.
> >> version
> >> JBoss Admin Command-line Interface
> >> JBOSS_HOME: null
> >> JBoss AS release: <connect to the controller and re-run the
> >> version command to see the release info>
> >> JAVA_HOME: null
> >> java.version: 1.8.0_45
> >> java.vm.vendor: Oracle Corporation
> >> java.vm.version: 25.45-b02
> >> os.name: Linux
> >> os.version: 4.1.6-200.fc22.x86_64
> >> connect
> >> Warning! The CLI is running in a non-modular environment and
> >> cannot load commands from management extensions.
> >> version
> >> JBoss Admin Command-line Interface
> >> JBOSS_HOME: null
> >> JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
> >> JAVA_HOME: null
> >> java.version: 1.8.0_45
> >> java.vm.vendor: Oracle Corporation
> >> java.vm.version: 25.45-b02
> >> os.name: Linux
> >> os.version: 4.1.6-200.fc22.x86_64
> >> echo tim
> >> tim
> >>
> >> 'version', 'connect', 'version', and 'echo tim' lines are now in
> >> the output, along with some information messages. I think this
> >> makes the output more useful, since the user can see which
> >> command was entered before the output or possible error occurs.
> >> It shouldn't have an impact on existing scripts, because the
> >> output still contains the expected output from any command and
> >> still ends with the last command output, so if someone is doing
> >> string analysis I wouldn't expect it to fail.
> >>
> >> I'd actually prefer to extend this change and add the command
> >> prompts into the output as well. Which would look like this:
> >>
> >> [joe at localhost bin]$ ./jboss-cli.sh --commands=version,"alias
> >> v=version",connect,v,"echo tim"
> >> [disconnected /] version
> >> JBoss Admin Command-line Interface
> >> JBOSS_HOME:
> >> /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
> >> JBoss AS release: <connect to the controller and re-run the
> >> version command to see the release info>
> >> JAVA_HOME: null
> >> java.version: 1.8.0_45
> >> java.vm.vendor: Oracle Corporation
> >> java.vm.version: 25.45-b02
> >> os.name: Linux
> >> os.version: 4.1.6-200.fc22.x86_64
> >> [disconnected /] alias v=version
> >> [disconnected /] connect
> >> [standalone at localhost:9990 /] v
> >> JBoss Admin Command-line Interface
> >> JBOSS_HOME:
> >> /home/joe/ideaProjects/wildfly-core/build/target/wildfly-core-2.0.0.CR1-SNAPSHOT
> >> JBoss AS release: 2.0.0.CR1-SNAPSHOT "Kenny"
> >> JAVA_HOME: null
> >> java.version: 1.8.0_45
> >> java.vm.vendor: Oracle Corporation
> >> java.vm.version: 25.45-b02
> >> os.name: Linux
> >> os.version: 4.1.6-200.fc22.x86_64
> >> [standalone at localhost:9990 /] echo tim
> >> tim
> >> [standalone at localhost:9990 /]
> >>
> >> This, to me, adds more information to the output making it more
> >> useful. I like the idea of the non-interactive mode imitating the
> >> interactive mode closely and essentially pretending to be a user,
> >> and this output is almost identical to a user entering these
> >> commands one at a time. It does, however, modify the end of the
> >> output stream which could break analysis scripts. A contains
> >> would be fine, but an ends-with would be broken because of the
> >> last prompt.
> >>
> >> Normal interactive mode output is unchanged. This will only effect
> >> '--file=' and '--commands=' output.
> >>
> >> Thoughts?
> >>
> >> Joe Wertz
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

From rodakr at gmx.ch  Sat Sep  5 05:34:25 2015
From: rodakr at gmx.ch (Radoslaw Rodak)
Date: Sat, 5 Sep 2015 11:34:25 +0200
Subject: [wildfly-dev] CLI batches in control flow blocks
In-Reply-To: <55E97442.50302@redhat.com>
References: <55E86A4D.80809@redhat.com> <55E8C53A.6040207@redhat.com>
	<55E9324F.5060302@redhat.com> <55E97442.50302@redhat.com>
Message-ID: <7078CAAB-2F5C-497C-9472-09CC060B3F95@gmx.ch>

Why not provide CLI out of the box in WildFly  combined with one of scripting language, something like this ?

https://developer.jboss.org/wiki/AdvancedCLIScriptingWithGroovyRhinoJythonEtc

 

Am 04.09.2015 um 12:36 schrieb Tom Fonteyne <tfonteyn at redhat.com>:

> IMHO.... you cannot use if/then in batches anyhow, e.g:
> 
> batch
> ...
> if ...
> ...
> then
> ...
> fi
> ...
> run-batch
> 
> fails. So the use of if/then was of very limited use anyhow.
> 
> Having multi-level batch would be ideal.
> Removing auto-batch from if/then blocks would at least allow batches 
> "around" them to work properly which would be a big win anyhow.
> 
> just my ?0.02 of course
> Tom
> 
> 
> On 04/09/15 06:55, Alexey Loubyansky wrote:
>> On 09/04/2015 12:10 AM, Brian Stansberry wrote:
>>> The risk is this can break existing scripts, which we've sought to
>>> avoid. A couple breakage scenarios:
>>> 
>>> 1) Step 1 needs to happen in a batch with Step 2; now it won't so the
>>> script breaks.
>>> 2) Step 1 works but for some reason Step 2 fails, and now Step 1 isn't
>>> rolled back.
>>> 
>>> The first one is more likely, but the second one is a bigger concern, as
>>> the user may not be aware Step 1 wasn't rolled back.
>>> 
>>> Do you have any sense of how common either of those scenarios would be?
>> Unfortunately, no. I don't get much feedback on this except for created
>> issues that I referenced.
>> I wouldn't bring it up unless this wasn't a major version release, of
>> course.
>> 
>>> Below are bad ideas that I wrote down and then thought better of, but
>>> I'll send them in case it sparks a thought.
>>> 
>>> I. Since there is already logic for dropping out of the batch for things
>>> like cd, ls, could it be modified as follows?
>>> 
>>> a) Close any current batch and execute that batch.
>>> b) Execute the cd, ls, etc
>>> c) Proceed, and if the next statement isn't a cd, ls etc, start a new batch.
>>> 
>>> That seems like a better semantic for cd and ls anyway.
>> I don't think so. The batch mode is also a composition/editing mode. cd
>> and ls are useful when writing commands/operations that should be added
>> to the batch. Imagine editing a batch and wishing to cd before entering
>> next lines. That won't be possible without explicit holback-batch, cd
>> and then batch again. That would be inconvenient.
>> 
>>> With that, reload and shutdown can be treated the same as cd, ls.
>> For reload and shutdown that does seem to make sense. So, a possible
>> alternative is making them exceptions.
>> 
>>> Why a bad idea? Doing it as I suggest has the same two drawbacks as
>>> requiring the user to declare the batch. :( Just perhaps less likely to
>>> occur.
>>> 
>>> II. Is an --auto-batch=true|false param to if/else/try/catch/finally
>>> possible? Why a bad idea? To solve the breakage problem it would need to
>>> be 'true' by default, thus forcing users forever to declare that they
>>> want the non-broken mode, *plus* they have to declare the batches.
>> As a param to if/else/try/catch/finally this doesn't make sense to me.
>> Because then the user could simply explicitly start bodies with batch.
>> This kind of argument could make sense as a launching script argument
>> for the whole cli session, imo.
>> 
>> Thanks,
>> Alexey
>> 
>>> 
>>> On 9/3/15 10:42 AM, Alexey Loubyansky wrote:
>>>> Hello everyone,
>>>> 
>>>> I've been thinking about changing how the bodies of if-else and
>>>> try-catch-finally are treated by the CLI.
>>>> 
>>>> Up until now every control flow block (i.e. between if and else, between
>>>> else and end-if, etc) was executed as a batch. So, when a block was
>>>> selected for the execution, the CLI would enter the batch mode and
>>>> proceed adding operations (and commands translated to operations) to it.
>>>> If a command can't be translated to an operation, it would be executed
>>>> outside the batch immediately (that's done for commands like cd, ls,
>>>> etc). After the last line of the body processed, the batch (if not
>>>> empty) is executed.
>>>> 
>>>> But this doesn't work when mixing operations with shutdown or reload
>>>> commands (they do translate to operations but they have additional logic
>>>> related to re-connecting). shutdown/reload will be executed outside the
>>>> batch and before the batch is complete.
>>>> 
>>>> Currently open issues for this
>>>> https://issues.jboss.org/browse/WFCORE-876
>>>> https://issues.jboss.org/browse/WFCORE-533
>>>> 
>>>> So, I think it was a mistake to execute the bodies of control flow
>>>> blocks as batches. It would be better leave them as usual sequences of
>>>> command lines and if the user wants a batch, he/she could add batch
>>>> command explicitly.
>>>> 
>>>> I wanted to ask for opinions. Could we make this change in WildFly 10?
>>>> 
>>>> Thanks,
>>>> Alexey
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> 
>>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> -- 
> Tom R. Fonteyne - SSME
> Red Hat - UK
> EMEA GSS SEG-Middleware
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150905/4c155018/attachment-0001.html 

From hbraun at redhat.com  Sat Sep  5 07:35:54 2015
From: hbraun at redhat.com (Heiko Braun)
Date: Sat, 5 Sep 2015 13:35:54 +0200
Subject: [wildfly-dev] CLI batches in control flow blocks
In-Reply-To: <7078CAAB-2F5C-497C-9472-09CC060B3F95@gmx.ch>
References: <55E86A4D.80809@redhat.com> <55E8C53A.6040207@redhat.com>
	<55E9324F.5060302@redhat.com> <55E97442.50302@redhat.com>
	<7078CAAB-2F5C-497C-9472-09CC060B3F95@gmx.ch>
Message-ID: <4AA73117-8613-4298-9F65-7A59E07A013B@redhat.com>

full scripting support: yes
using CLI command strings for that: no

if we go for scripting then regulat DMR makes more sense IMO

Sent from my iPhone

> On 05 Sep 2015, at 11:34, Radoslaw Rodak <rodakr at gmx.ch> wrote:
> 
> Why not provide CLI out of the box in WildFly  combined with one of scripting language, something like this ?
> 
> https://developer.jboss.org/wiki/AdvancedCLIScriptingWithGroovyRhinoJythonEtc
> 
>  
> 
>> Am 04.09.2015 um 12:36 schrieb Tom Fonteyne <tfonteyn at redhat.com>:
>> 
>> IMHO.... you cannot use if/then in batches anyhow, e.g:
>> 
>> batch
>> ...
>> if ...
>> ...
>> then
>> ...
>> fi
>> ...
>> run-batch
>> 
>> fails. So the use of if/then was of very limited use anyhow.
>> 
>> Having multi-level batch would be ideal.
>> Removing auto-batch from if/then blocks would at least allow batches 
>> "around" them to work properly which would be a big win anyhow.
>> 
>> just my ?0.02 of course
>> Tom
>> 
>> 
>>> On 04/09/15 06:55, Alexey Loubyansky wrote:
>>>> On 09/04/2015 12:10 AM, Brian Stansberry wrote:
>>>> The risk is this can break existing scripts, which we've sought to
>>>> avoid. A couple breakage scenarios:
>>>> 
>>>> 1) Step 1 needs to happen in a batch with Step 2; now it won't so the
>>>> script breaks.
>>>> 2) Step 1 works but for some reason Step 2 fails, and now Step 1 isn't
>>>> rolled back.
>>>> 
>>>> The first one is more likely, but the second one is a bigger concern, as
>>>> the user may not be aware Step 1 wasn't rolled back.
>>>> 
>>>> Do you have any sense of how common either of those scenarios would be?
>>> Unfortunately, no. I don't get much feedback on this except for created
>>> issues that I referenced.
>>> I wouldn't bring it up unless this wasn't a major version release, of
>>> course.
>>> 
>>>> Below are bad ideas that I wrote down and then thought better of, but
>>>> I'll send them in case it sparks a thought.
>>>> 
>>>> I. Since there is already logic for dropping out of the batch for things
>>>> like cd, ls, could it be modified as follows?
>>>> 
>>>> a) Close any current batch and execute that batch.
>>>> b) Execute the cd, ls, etc
>>>> c) Proceed, and if the next statement isn't a cd, ls etc, start a new batch.
>>>> 
>>>> That seems like a better semantic for cd and ls anyway.
>>> I don't think so. The batch mode is also a composition/editing mode. cd
>>> and ls are useful when writing commands/operations that should be added
>>> to the batch. Imagine editing a batch and wishing to cd before entering
>>> next lines. That won't be possible without explicit holback-batch, cd
>>> and then batch again. That would be inconvenient.
>>> 
>>>> With that, reload and shutdown can be treated the same as cd, ls.
>>> For reload and shutdown that does seem to make sense. So, a possible
>>> alternative is making them exceptions.
>>> 
>>>> Why a bad idea? Doing it as I suggest has the same two drawbacks as
>>>> requiring the user to declare the batch. :( Just perhaps less likely to
>>>> occur.
>>>> 
>>>> II. Is an --auto-batch=true|false param to if/else/try/catch/finally
>>>> possible? Why a bad idea? To solve the breakage problem it would need to
>>>> be 'true' by default, thus forcing users forever to declare that they
>>>> want the non-broken mode, *plus* they have to declare the batches.
>>> As a param to if/else/try/catch/finally this doesn't make sense to me.
>>> Because then the user could simply explicitly start bodies with batch.
>>> This kind of argument could make sense as a launching script argument
>>> for the whole cli session, imo.
>>> 
>>> Thanks,
>>> Alexey
>>> 
>>>> 
>>>>> On 9/3/15 10:42 AM, Alexey Loubyansky wrote:
>>>>> Hello everyone,
>>>>> 
>>>>> I've been thinking about changing how the bodies of if-else and
>>>>> try-catch-finally are treated by the CLI.
>>>>> 
>>>>> Up until now every control flow block (i.e. between if and else, between
>>>>> else and end-if, etc) was executed as a batch. So, when a block was
>>>>> selected for the execution, the CLI would enter the batch mode and
>>>>> proceed adding operations (and commands translated to operations) to it.
>>>>> If a command can't be translated to an operation, it would be executed
>>>>> outside the batch immediately (that's done for commands like cd, ls,
>>>>> etc). After the last line of the body processed, the batch (if not
>>>>> empty) is executed.
>>>>> 
>>>>> But this doesn't work when mixing operations with shutdown or reload
>>>>> commands (they do translate to operations but they have additional logic
>>>>> related to re-connecting). shutdown/reload will be executed outside the
>>>>> batch and before the batch is complete.
>>>>> 
>>>>> Currently open issues for this
>>>>> https://issues.jboss.org/browse/WFCORE-876
>>>>> https://issues.jboss.org/browse/WFCORE-533
>>>>> 
>>>>> So, I think it was a mistake to execute the bodies of control flow
>>>>> blocks as batches. It would be better leave them as usual sequences of
>>>>> command lines and if the user wants a batch, he/she could add batch
>>>>> command explicitly.
>>>>> 
>>>>> I wanted to ask for opinions. Could we make this change in WildFly 10?
>>>>> 
>>>>> Thanks,
>>>>> Alexey
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> -- 
>> Tom R. Fonteyne - SSME
>> Red Hat - UK
>> EMEA GSS SEG-Middleware
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150905/26953c89/attachment.html 

From tcerar at redhat.com  Wed Sep  9 08:45:26 2015
From: tcerar at redhat.com (Tomaz Cerar)
Date: Wed, 9 Sep 2015 14:45:26 +0200
Subject: [wildfly-dev] WildFly vs EAP Quickstarts (synchronisation PR
	proposed)
In-Reply-To: <CA+kEUD0ExztTdmAo0L-wnCSgGZ5e24shk=mKKGquPtOYgbpnSA@mail.gmail.com>
References: <CA+kEUD1q5tanpcG8q9-Bh9761P+TsXPU-Re4XfMKXiZjeSDh3A@mail.gmail.com>
	<CA+kEUD0AK9RN9T7FxOKzkO4ACroF5dX1n-y8JEgh=9DBkbEjxg@mail.gmail.com>
	<CA+kEUD0ExztTdmAo0L-wnCSgGZ5e24shk=mKKGquPtOYgbpnSA@mail.gmail.com>
Message-ID: <CA+19isM7EH5b+iDtuLEnzD5CKkOiGZSvcMw7O-iUv1rD6hPgWg@mail.gmail.com>

On Wed, Sep 9, 2015 at 2:43 AM, Rafael Benevides <rbenevid at redhat.com>
wrote:

> this PR now points to 10.x branch:
> https://github.com/wildfly/quickstart/pull/72
>


I've already merged your PR.

Thank you for this huge effort.

--
tomaz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150909/33f77f6a/attachment.html 

From rory.odonnell at oracle.com  Wed Sep  9 13:28:02 2015
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Wed, 9 Sep 2015 18:28:02 +0100
Subject: [wildfly-dev] Project Jigsaw: Early-Access Builds available on
	jdk9.java.net/jigsaw
Message-ID: <55F06C22.1090505@oracle.com>


Hi Jason/Tomaz,

Early-access builds of JDK 9 with Project Jigsaw are available for 
download at jdk9.java.net/jigsaw <http://jdk9.java.net/jigsaw>.

The EA builds contain the latest prototype implementation of JSR 376 
<http://openjdk.java.net/projects/jigsaw/spec>, the Java Platform Module 
System,
as well as that of the JDK-specific APIs and tools described in JEP 261 
<http://openjdk.java.net/jeps/261>.

If you'd like to try out the EA builds, by far the most helpful things 
you can do are:

  *

    Try to run existing applications, without change, on these builds to
    see whether the module system, or the modularization of the
    platform, breaks your code or identifies code that depends upon
    JDK-internal APIs or other unspecified aspects of the platform.

  *

    Experiment with the module system itself, perhaps by following the
    quick start guide
    <http://openjdk.java.net/projects/jigsaw/quick-start>, and start
    thinking about how to migrate existing libraries and application
    components to modules. We hope to publish some specific migration
    tips shortly.

Please send usage questions and experience reports to the jigsaw-dev 
<http://mail.openjdk.java.net/mailman/listinfo/jigsaw-dev> list. 
Specific suggestions about the design of the module system should be 
sent to the JSR 376 Expert Group's comments list 
<mailto:jpms-spec-comments at openjdk.java.net>.

For more information please seen Mark Reinhold's mail [1]

Rgds,Rory

[1]http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-September/004480.html

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150909/36fceee3/attachment.html 

From arjan.tijms at gmail.com  Thu Sep 10 14:41:02 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 10 Sep 2015 20:41:02 +0200
Subject: [wildfly-dev] Upcoming WF10 Dates (Reminder)
In-Reply-To: <627F9528-0957-49B6-8DDB-E4D6A4138AEF@redhat.com>
References: <627F9528-0957-49B6-8DDB-E4D6A4138AEF@redhat.com>
Message-ID: <CAE=-AhD6oq4GVWMD8dDxFGZYV8SRmOPjz+wxv9y=BjCbN-anng@mail.gmail.com>

Hi,

On Thu, Aug 13, 2015 at 7:42 PM, Jason Greene <jason.greene at redhat.com> wrote:
> WildFly 10 CR1              - September 9th

I looked at the download page, but the CR1 version doesn't seem to be
there. Has it been released somewhere anyway, or is the release
delayed?

Kind regards,
Arjan

From jason.greene at redhat.com  Thu Sep 10 15:09:15 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 10 Sep 2015 14:09:15 -0500
Subject: [wildfly-dev] Upcoming WF10 Dates (Reminder)
In-Reply-To: <CAE=-AhD6oq4GVWMD8dDxFGZYV8SRmOPjz+wxv9y=BjCbN-anng@mail.gmail.com>
References: <627F9528-0957-49B6-8DDB-E4D6A4138AEF@redhat.com>
	<CAE=-AhD6oq4GVWMD8dDxFGZYV8SRmOPjz+wxv9y=BjCbN-anng@mail.gmail.com>
Message-ID: <CB364C98-E42B-40C3-8803-C5EDA7509042@redhat.com>


> On Sep 10, 2015, at 1:41 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
> 
> Hi,
> 
> On Thu, Aug 13, 2015 at 7:42 PM, Jason Greene <jason.greene at redhat.com> wrote:
>> WildFly 10 CR1              - September 9th
> 
> I looked at the download page, but the CR1 version doesn't seem to be
> there. Has it been released somewhere anyway, or is the release
> delayed?

Yes we are delayed on some intermittent failures caused by a recent update. Yesterday I moved the date to Friday as a placeholder for now. I?ll provide a more detailed update soon. 

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From jason.greene at redhat.com  Mon Sep 14 00:32:00 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Sun, 13 Sep 2015 23:32:00 -0500
Subject: [wildfly-dev] WF10 CR1 Delay - Tentatively Moved to the 16th
Message-ID: <8AC45A63-8F78-41FF-86FF-3393B0A9CC15@redhat.com>

Hello Everyone,

As mentioned Thursday, the CR1 release was delayed on some intermittent failures in our main test suite related to a new messaging update that resolves a number of reported bugs. The good news is that the those have been resolved, but we are still seeing some related regressions in the EE TCK test suite. I have tentatively pushed the date for CR1 to Wed the 16th.

I apologize for the delay, but promise to provide updates along the way.

Thanks!
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat



From eduardo at dotmac.com.br  Mon Sep 14 13:38:58 2015
From: eduardo at dotmac.com.br (Eduardo Medeiros)
Date: Mon, 14 Sep 2015 14:38:58 -0300
Subject: [wildfly-dev] WildFly - encrypt datasource.
Message-ID: <CAJ6L+YGQ-W=HT6_cQ5Q3nd6R9goWpbMNC-BGB1+F9mJSrAD9pA@mail.gmail.com>

Hello Guys,

I would like to know if there is a road map to add a feature for encrypt
password from data sources using HAL console.

Nowadays, I know that this configuration is possible using the keytool and
vault.sh, but is a little bit hard and confused.

--
Thank you,
Eduardo Medeiros.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150914/7744679b/attachment.html 

From alex_orl1079 at yahoo.it  Mon Sep 14 19:55:34 2015
From: alex_orl1079 at yahoo.it (alex orl)
Date: Mon, 14 Sep 2015 23:55:34 +0000 (UTC)
Subject: [wildfly-dev] EntityManager is not injected inside a Jboss module
Message-ID: <1929317343.3448750.1442274934509.JavaMail.yahoo@mail.yahoo.com>

I'm working with jboss wildfly 9. I have a provider deployed as module into the ? modules ?directory.Then i have a jpa project with DAO pattern writing and reading inside my database. I want to handle the DAO transaction using JTA but in order to make the DAO class visibile to myprovider i need to put the DAO JPA project inside the modules directory too.Now i m facing ?the real problem: it seems i cannot use the PersistenceContext annotation to inject the entity manager into my EntityManager variable wich is always null. Why i cannot inject the a context into a jar modules? What am i wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150914/8437349a/attachment.html 

From spaulger at codezen.co.uk  Tue Sep 15 09:38:55 2015
From: spaulger at codezen.co.uk (Simon Paulger)
Date: Tue, 15 Sep 2015 14:38:55 +0100
Subject: [wildfly-dev] Wildfly Redis infinispan cache store
In-Reply-To: <E9381A0F-D9B4-47BE-9D1D-45076BE7DF15@redhat.com>
References: <CAHadGstN++dRG6A5UYMZ2BaGNwfucTXgq9un8YykDFs0Yr08CQ@mail.gmail.com>
	<E9381A0F-D9B4-47BE-9D1D-45076BE7DF15@redhat.com>
Message-ID: <5C213E3E-A418-454B-8C14-CBA883C05CAF@codezen.co.uk>

Hi Jason,

I have developed a redis cache store which has now been completed and released under the infinispan org as part of version 8, available through central.

I had begun to look at what changes would be required under wildfly. I have made changes to the xml reader and writer for config for a concrete redis-store type but haven't worked out how to update the web ui and cli.

This got me thinking as to whether a concrete config tag is required at all since there is always the custom store.

Therefore, I thought I'd check. What changes should I be developing to make my redis integration in to wildfly 10?

Thanks
Simon

Sent from my iPhone

> On 28 Jul 2015, at 21:22, Jason Greene <jason.greene at redhat.com> wrote:
> 
> 
>> On Jul 28, 2015, at 3:04 PM, Simon Paulger <spaulger at codezen.co.uk> wrote:
>> 
>> Hi,
>> 
>> My company uses JBoss AS 7 (before Wildfly I know). We also use Redis cache store for PHP stacks and I'd like to be able to do the same for Wildfly (I'm considering upgrade paths).
>> 
>> I see there is an old JIRA enhancement issue raised here: https://issues.jboss.org/browse/ISPN-3465
>> 
>> I was wondering what the appetite for creating a Redis cache store is. If this were something I were to develop in both inifinispan and wildfly, would it be well received by the JBoss community?
> 
> Hi Simon, 
> 
> Thanks for the interest, and it sounds great to me! 
> 
> I would recommend starting by posting to infinispan-dev your interest in the feature (if you haven?t already), and they can help you get started. I would imagine the infinispan memcached code is a good starting point, and may in fact be adaptable to the Redis protocol, perhaps by forking it.
> 
> One thats done there is some integration bits on the WildFly side, but I wouldn?t worry about that until its shipped in an infinispan release.
> 
> Thanks,
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150915/09b82754/attachment.html 

From ehugonne at redhat.com  Wed Sep 16 13:33:17 2015
From: ehugonne at redhat.com (Emmanuel Hugonnet)
Date: Wed, 16 Sep 2015 19:33:17 +0200
Subject: [wildfly-dev] Redesigning http-upgrade configuration for management
Message-ID: <55F9A7DD.9050504@redhat.com>

Hi,
This is for management interfaces only.
We need a capability to cover the fact that some management interfaces may provides jboss-remoting endpoints to be used by JMX.
The native-interface provides this capability at the resource level, so this is nice and straightforward.
Currently making an http-interface http-upgrade-enabled is done through the well named 'http-upgrade-enabled' attribute.
But because of the use of an attribute we have no nice standard way to register the capability.
One way to do that would be to use a child resource, "http-upgrade-support=on" to define the fact that this http-interface supports upgrade.
We could then move the code and services associated with this support to the addHandler and removeHandler.
To keep backward compatibility :
 - for the add / remove of current resource :
it is easy to add a new step to add the new resource on the http-interface addHandler, and do the same for removal.
 - for the beloved http-upgrade-enabled attribute which is writeable but doesn't really do anything until the interface is restarted.
Of course it could get deprecated but we would still have a writeable attribute that represents a duplicate state of the child resource.
We may want to use the write-attribute handler on this attribute to call the resource ops without impacting the services, just changing the
model.

What do you think ?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150916/792556f2/attachment.bin 

From brian.stansberry at redhat.com  Wed Sep 16 14:11:31 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 16 Sep 2015 13:11:31 -0500
Subject: [wildfly-dev] Redesigning http-upgrade configuration for
 management
In-Reply-To: <55F9A7DD.9050504@redhat.com>
References: <55F9A7DD.9050504@redhat.com>
Message-ID: <55F9B0D3.5080008@redhat.com>

On 9/16/15 12:33 PM, Emmanuel Hugonnet wrote:
> Hi,
> This is for management interfaces only.
> We need a capability to cover the fact that some management interfaces may provides jboss-remoting endpoints to be used by JMX.
> The native-interface provides this capability at the resource level, so this is nice and straightforward.
> Currently making an http-interface http-upgrade-enabled is done through the well named 'http-upgrade-enabled' attribute.
> But because of the use of an attribute we have no nice standard way to register the capability.
> One way to do that would be to use a child resource, "http-upgrade-support=on" to define the fact that this http-interface supports upgrade.

We need a different name for this. Address elements should be of the 
form category=specific_name.

This resource is the logical encapsulation of some sort of 
functionality. So we need to brainstorm and define what exactly that 
functionality is and what it may become and then hopefully the name for 
the resource will fall out of that.

For example, I believe http-upgrade is an implementation detail. What 
the resource is really about is providing JBoss Remoting-based 
management in an HTTP environment. We refer to that elsewhere as 
"native" (i.e. in 
/core-service=management/management-interface=native-interface) So is 
this resource primarily about native management?

> We could then move the code and services associated with this support to the addHandler and removeHandler.
> To keep backward compatibility :
>   - for the add / remove of current resource :
> it is easy to add a new step to add the new resource on the http-interface addHandler, and do the same for removal.

The removal should require reload, to encourage the user to understand 
that they may lose their connection to the server, and to avoid creating 
another situation where executing an op can result in an unclean 
execution from the client's point of view due to the connection closing.

>   - for the beloved http-upgrade-enabled attribute which is writeable but doesn't really do anything until the interface is restarted.
> Of course it could get deprecated but we would still have a writeable attribute that represents a duplicate state of the child resource.
> We may want to use the write-attribute handler on this attribute to call the resource ops without impacting the services, just changing the
> model.

If they set the value to 'false', yes. If they set it to true, putting 
the server into reload required is enough, as the boot handling should 
be adding the child resource when http-upgrade-enabled is 'true'.

>
> What do you think ?
>

There's the fact that http-upgrade-enabled currently supports 
expressions. We need to define all the semantics around that. Some thoughts:

1) If the user stores the expression value in the vault, that just can't 
work, as the evaluation of the expression in order to decide whether to 
add the child resource has to happen before the vault is available. I 
have no problem with that constraint, since using a vault expression 
here would be a real corner case. And this attribute has never been in 
EAP where we might have a greater requirement to continue to support old 
weird corner cases.

2) If the value doesn't have an expression, we can drop the attribute 
when marshaling, and just write the child element. But if it does have 
an expression we have to marshal the attribute back to xml. 
Unfortunately this precludes dropping the attribute from the current 
version of the xsd. :(

>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From jperkins at redhat.com  Wed Sep 16 20:01:42 2015
From: jperkins at redhat.com (James Perkins)
Date: Wed, 16 Sep 2015 17:01:42 -0700
Subject: [wildfly-dev] WildFly Arquillian for Domain Servers
Message-ID: <CADGwLpih5jrpAA1jbZw8KJx8G4YisjZqkXdXrzMBApqjdH0f=g@mail.gmail.com>

Does anyone use wildfly-arquillian with domain servers? If so does it work?

I was processing pull request for the wildfly-arquillian [1] project.
During the process I found a pull requestion for an issue with using
arquillian on domain servers [2]. This led me to look at the to look at the
domain adapters. Looking through the code it looks quite out of date and
potentially wrong in some places. I started updating and noticed that the
tests were ignored. I re-enabled them and realized the adapter doesn't seem
to work at all.

The main issue seems to be that deployments are not rolled out to the
servers. If I change the deployment plan to rollback on error it has an
error message that states "WFLYDC0022: Operation failed or was rolled back
on all servers.". No other reason. I can start the same server used in
domain mode and execute CLI commands or use an operation identical to the
one created by the deployment plan and all seems to work fine. I assume
this issue is unique to arquillian.

I'm at the point where I don't want to invest anymore time if no one is
using arquillian for domain servers. If anyone is using it and has an
example application that you could share that would be helpful :)

I propose if no one is using it, we scrap it.

If people *are* using it I propose we do a redesign it a bit. There's
mainly some things exposed I don't think should be exposed. I could keep
compatibility too fairly easily. It would be about the same amount of work
either way I think.

If anyone else has other ideas I'm open to that as well.


[1]: https://github.com/wildfly/wildfly-arquillian
[2]: https://issues.jboss.org/browse/ARQ-1971

--
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150916/7802a7f4/attachment-0001.html 

From jason.greene at redhat.com  Thu Sep 17 02:35:39 2015
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 17 Sep 2015 01:35:39 -0500
Subject: [wildfly-dev] WildFly 10 CR1 is released!
Message-ID: <3C4A9953-31D6-499A-AD6F-10D8063869CC@redhat.com>

Hello Everyone,

WildFly 10 CR1 is now available for download!

https://developer.jboss.org/wiki/WildFly1000CR1ReleaseNotes
https://github.com/wildfly/wildfly/tree/10.0.0.CR1
http://wildfly.org/downloads/

The next release, CR2, is planned for next week Wednesday the 23rd.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


From ehugonne at redhat.com  Thu Sep 17 03:58:04 2015
From: ehugonne at redhat.com (Emmanuel Hugonnet)
Date: Thu, 17 Sep 2015 09:58:04 +0200
Subject: [wildfly-dev] Redesigning http-upgrade configuration for
 management
In-Reply-To: <55F9B0D3.5080008@redhat.com>
References: <55F9A7DD.9050504@redhat.com> <55F9B0D3.5080008@redhat.com>
Message-ID: <55FA728C.2080803@redhat.com>



Le 16/09/2015 20:11, Brian Stansberry a ?crit :
> On 9/16/15 12:33 PM, Emmanuel Hugonnet wrote:
>> Hi,
>> This is for management interfaces only.
>> We need a capability to cover the fact that some management interfaces may provides jboss-remoting endpoints to be used by JMX.
>> The native-interface provides this capability at the resource level, so this is nice and straightforward.
>> Currently making an http-interface http-upgrade-enabled is done through the well named 'http-upgrade-enabled' attribute.
>> But because of the use of an attribute we have no nice standard way to register the capability.
>> One way to do that would be to use a child resource, "http-upgrade-support=on" to define the fact that this http-interface supports upgrade.
> 
> We need a different name for this. Address elements should be of the 
> form category=specific_name.
> 
> This resource is the logical encapsulation of some sort of 
> functionality. So we need to brainstorm and define what exactly that 
> functionality is and what it may become and then hopefully the name for 
> the resource will fall out of that.
> 
> For example, I believe http-upgrade is an implementation detail. What 
> the resource is really about is providing JBoss Remoting-based 
> management in an HTTP environment. We refer to that elsewhere as 
> "native" (i.e. in 
> /core-service=management/management-interface=native-interface) So is 
> this resource primarily about native management?

I agree so something along 'native-support=on'.


> 
>> We could then move the code and services associated with this support to the addHandler and removeHandler.
>> To keep backward compatibility :
>>   - for the add / remove of current resource :
>> it is easy to add a new step to add the new resource on the http-interface addHandler, and do the same for removal.
> 
> The removal should require reload, to encourage the user to understand 
> that they may lose their connection to the server, and to avoid creating 
> another situation where executing an op can result in an unclean 
> execution from the client's point of view due to the connection closing.

Yes of course

> 
>>   - for the beloved http-upgrade-enabled attribute which is writeable but doesn't really do anything until the interface is restarted.
>> Of course it could get deprecated but we would still have a writeable attribute that represents a duplicate state of the child resource.
>> We may want to use the write-attribute handler on this attribute to call the resource ops without impacting the services, just changing the
>> model.
> 
> If they set the value to 'false', yes. If they set it to true, putting 
> the server into reload required is enough, as the boot handling should 
> be adding the child resource when http-upgrade-enabled is 'true'.
> 
>>
>> What do you think ?
>>
> 
> There's the fact that http-upgrade-enabled currently supports 
> expressions. We need to define all the semantics around that. Some thoughts:
> 
> 1) If the user stores the expression value in the vault, that just can't 
> work, as the evaluation of the expression in order to decide whether to 
> add the child resource has to happen before the vault is available. I 
> have no problem with that constraint, since using a vault expression 
> here would be a real corner case. And this attribute has never been in 
> EAP where we might have a greater requirement to continue to support old 
> weird corner cases.
> 
> 2) If the value doesn't have an expression, we can drop the attribute 
> when marshaling, and just write the child element. But if it does have 
> an expression we have to marshal the attribute back to xml. 
> Unfortunately this precludes dropping the attribute from the current 
> version of the xsd. :(

Yes and in the model itself

> 
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150917/04941df6/attachment.bin 

From rhatlapa at redhat.com  Thu Sep 17 04:22:36 2015
From: rhatlapa at redhat.com (Radim Hatlapatka)
Date: Thu, 17 Sep 2015 10:22:36 +0200
Subject: [wildfly-dev] WildFly Arquillian for Domain Servers
In-Reply-To: <CADGwLpih5jrpAA1jbZw8KJx8G4YisjZqkXdXrzMBApqjdH0f=g@mail.gmail.com>
References: <CADGwLpih5jrpAA1jbZw8KJx8G4YisjZqkXdXrzMBApqjdH0f=g@mail.gmail.com>
Message-ID: <55FA784C.5030902@redhat.com>

Hi James,

I am using it. Currently as workaround to the [1], I am usually 
connecting to already running server instead of starting it with 
arquillian because of that issue.

I have also encountered that arquillian deployments management doesn't 
work when the server is started by arquillian, thereby I am managing 
deployments outside of arquillian and handling deployments via WildFly 
management API.

Radim

[1] https://issues.jboss.org/browse/ARQ-1971

On 09/17/2015 02:01 AM, James Perkins wrote:
> Does anyone use wildfly-arquillian with domain servers? If so does it 
> work?
>
> I was processing pull request for the wildfly-arquillian [1] project. 
> During the process I found a pull requestion for an issue with using 
> arquillian on domain servers [2]. This led me to look at the to look 
> at the domain adapters. Looking through the code it looks quite out of 
> date and potentially wrong in some places. I started updating and 
> noticed that the tests were ignored. I re-enabled them and realized 
> the adapter doesn't seem to work at all.
>
> The main issue seems to be that deployments are not rolled out to the 
> servers. If I change the deployment plan to rollback on error it has 
> an error message that states "WFLYDC0022: Operation failed or was 
> rolled back on all servers.". No other reason. I can start the same 
> server used in domain mode and execute CLI commands or use an 
> operation identical to the one created by the deployment plan and all 
> seems to work fine. I assume this issue is unique to arquillian.
>
> I'm at the point where I don't want to invest anymore time if no one 
> is using arquillian for domain servers. If anyone is using it and has 
> an example application that you could share that would be helpful :)
>
> I propose if no one is using it, we scrap it.
>
> If people *are* using it I propose we do a redesign it a bit. There's 
> mainly some things exposed I don't think should be exposed. I could 
> keep compatibility too fairly easily. It would be about the same 
> amount of work either way I think.
>
> If anyone else has other ideas I'm open to that as well.
>
>
> [1]: https://github.com/wildfly/wildfly-arquillian
> [2]: https://issues.jboss.org/browse/ARQ-1971
>
> --
> James R. Perkins
> JBoss by Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150917/3ed3a3df/attachment.html 

From darran.lofthouse at jboss.com  Thu Sep 17 06:02:33 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 17 Sep 2015 11:02:33 +0100
Subject: [wildfly-dev] Redesigning http-upgrade configuration for
 management
In-Reply-To: <55F9A7DD.9050504@redhat.com>
References: <55F9A7DD.9050504@redhat.com>
Message-ID: <55FA8FB9.1060706@jboss.com>

Has this code been already written or not?  I was told the other day 
that this code was almost complete but now it is back to a design 
discussion.  I have also been told that this is not urgent for WildFly 10.

If this is still being designed and is not critical for WildFly 10 can I 
please ask that this is stopped and we pick this up later - this 
directly conflicts with changes I have already made to integrate Elytron.

In general my opinion is that instead of spending any effort on 
redesigning the current interfaces we should put the effort into the 
design of a new subsystem to contain these interfaces and that should 
start from the beginning where we can remodel the relationship between 
the two interface types.

Regards,
Darran Lofthouse.


On 16/09/15 18:33, Emmanuel Hugonnet wrote:
> Hi,
> This is for management interfaces only.
> We need a capability to cover the fact that some management interfaces may provides jboss-remoting endpoints to be used by JMX.
> The native-interface provides this capability at the resource level, so this is nice and straightforward.
> Currently making an http-interface http-upgrade-enabled is done through the well named 'http-upgrade-enabled' attribute.
> But because of the use of an attribute we have no nice standard way to register the capability.
> One way to do that would be to use a child resource, "http-upgrade-support=on" to define the fact that this http-interface supports upgrade.
> We could then move the code and services associated with this support to the addHandler and removeHandler.
> To keep backward compatibility :
>   - for the add / remove of current resource :
> it is easy to add a new step to add the new resource on the http-interface addHandler, and do the same for removal.
>   - for the beloved http-upgrade-enabled attribute which is writeable but doesn't really do anything until the interface is restarted.
> Of course it could get deprecated but we would still have a writeable attribute that represents a duplicate state of the child resource.
> We may want to use the write-attribute handler on this attribute to call the resource ops without impacting the services, just changing the
> model.
>
> What do you think ?
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From darran.lofthouse at jboss.com  Thu Sep 17 06:18:06 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 17 Sep 2015 11:18:06 +0100
Subject: [wildfly-dev] Redesigning http-upgrade configuration for
 management
In-Reply-To: <55F9B0D3.5080008@redhat.com>
References: <55F9A7DD.9050504@redhat.com> <55F9B0D3.5080008@redhat.com>
Message-ID: <55FA935E.7060807@jboss.com>

On 16/09/15 19:11, Brian Stansberry wrote:
> For example, I believe http-upgrade is an implementation detail. What
> the resource is really about is providing JBoss Remoting-based
> management in an HTTP environment. We refer to that elsewhere as
> "native" (i.e. in
> /core-service=management/management-interface=native-interface) So is
> this resource primarily about native management?

That sounds like where I was starting to come from regarding a new 
design to move this into a subsystem - we actually have a bit of a 
mixture when it comes to defining how different interfaces are exposed.

I was considering that at the top level we have a resource that 
represents the protocol being exposed.

I was then considering attributes to define how it is exposed, from 
subsequent capability related discussions those would probably have to 
be child resources.

In XML terms it would be something like: -

<native-interface sasl-authentication="...">
     <remoting />
     <direct socket-binding="..." />
     <http-upgrade use-http-binding="..." undertow-listener="..." />
</native-interface>
<http-interface http-authentication="...">
     <direct http-socket-binding="..." https-socket-binding="..."/>
     <undertow-listener name="..." context="/management" />
</http-interface>

Names chosen were just to illustrate the hierarchy but general principal 
was the parent is what is exposed, the child is how it is exposed.


From david.lloyd at redhat.com  Thu Sep 17 07:38:05 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 17 Sep 2015 06:38:05 -0500
Subject: [wildfly-dev] Redesigning http-upgrade configuration for
	management
In-Reply-To: <55FA935E.7060807@jboss.com>
References: <55F9A7DD.9050504@redhat.com> <55F9B0D3.5080008@redhat.com>
	<55FA935E.7060807@jboss.com>
Message-ID: <55FAA61D.2030201@redhat.com>

On 09/17/2015 05:18 AM, Darran Lofthouse wrote:
> On 16/09/15 19:11, Brian Stansberry wrote:
>> For example, I believe http-upgrade is an implementation detail. What
>> the resource is really about is providing JBoss Remoting-based
>> management in an HTTP environment. We refer to that elsewhere as
>> "native" (i.e. in
>> /core-service=management/management-interface=native-interface) So is
>> this resource primarily about native management?
>
> That sounds like where I was starting to come from regarding a new
> design to move this into a subsystem - we actually have a bit of a
> mixture when it comes to defining how different interfaces are exposed.
>
> I was considering that at the top level we have a resource that
> represents the protocol being exposed.
>
> I was then considering attributes to define how it is exposed, from
> subsequent capability related discussions those would probably have to
> be child resources.
>
> In XML terms it would be something like: -
>
> <native-interface sasl-authentication="...">
>       <remoting />
>       <direct socket-binding="..." />
>       <http-upgrade use-http-binding="..." undertow-listener="..." />
> </native-interface>
> <http-interface http-authentication="...">
>       <direct http-socket-binding="..." https-socket-binding="..."/>
>       <undertow-listener name="..." context="/management" />
> </http-interface>
>
> Names chosen were just to illustrate the hierarchy but general principal
> was the parent is what is exposed, the child is how it is exposed.

Assuming that we are still planning following through with moving 
everything into subsystems/enabling HC subsystems like we discussed last 
January, and given cap/req, shouldn't we seriously consider making it 
something more closely approximating this:

<subsystem xmlns="...remoting...">
     <endpoint id="management" name="${jboss.node.name}-management">
         <http-connector name="blah" sasl-authentication="rem-sasl" 
connector-ref="mgmt-connect" .../>
     </endpoint>
</subsystem>
<subsystem xmlns="...network...">
     <interface name="management">
         <inet-address value="127.0.0.1"/>
     </interface>
     <socket-binding-group name="standard-sockets">
         <socket-binding name="management-http" interface="management" 
port="${jboss.management.http.port:9990}"/>
         <socket-binding name="management-https" interface="management" 
port="${jboss.management.https.port:9993}"/>
         ...boring stuff here...
     </socket-binding-group>
</subsystem>
<subsystem xmlns="...sec-elytron...">
     <security-domain name="main-domain">
         <sasl-authentication name="rem-sasl">
             ...boring stuff here...
         </sasl-authentication>
         ...boring realm stuff here...
     </security-domain>
</subsystem>
<subsystem xmlns="...undertow...">
     <server name="mgmt-server">
         <http-listener name="default" socket-binding="management-http" 
.../>
         ...boring stuff here...
     </server>
     ...boring stuff here...
</subsystem>
<subsystem xmlns="...management...">
     <remoting endpoint="management"/>     // this is an attribute, not 
a sub-resource
     <security-domain name="main-domain"/> // this is an attribute, not 
a sub-resource
     ...boring stuff here...
</subsystem>

That said if we're not making the move to subsystems, I guess I don't 
really care how it's all laid out too much, but using cap/req whenever 
possible will make any such future move go more smoothly, IMO.

-- 
- DML

From darran.lofthouse at jboss.com  Thu Sep 17 07:48:50 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Thu, 17 Sep 2015 12:48:50 +0100
Subject: [wildfly-dev] Redesigning http-upgrade configuration for
 management
In-Reply-To: <55FAA61D.2030201@redhat.com>
References: <55F9A7DD.9050504@redhat.com> <55F9B0D3.5080008@redhat.com>
	<55FA935E.7060807@jboss.com> <55FAA61D.2030201@redhat.com>
Message-ID: <55FAA8A2.9090006@jboss.com>

+1 I now prefer the form of config where we do include the wiring 
together - but I think others don't, especially for the core management.

In the case of management it is trying to avoid depending on an endpoint 
and instead depend on an endpoint that is accessible in some way.

My suggestion was really a hybrid of the two.

On 17/09/15 12:38, David M. Lloyd wrote:
> On 09/17/2015 05:18 AM, Darran Lofthouse wrote:
>> On 16/09/15 19:11, Brian Stansberry wrote:
>>> For example, I believe http-upgrade is an implementation detail. What
>>> the resource is really about is providing JBoss Remoting-based
>>> management in an HTTP environment. We refer to that elsewhere as
>>> "native" (i.e. in
>>> /core-service=management/management-interface=native-interface) So is
>>> this resource primarily about native management?
>>
>> That sounds like where I was starting to come from regarding a new
>> design to move this into a subsystem - we actually have a bit of a
>> mixture when it comes to defining how different interfaces are exposed.
>>
>> I was considering that at the top level we have a resource that
>> represents the protocol being exposed.
>>
>> I was then considering attributes to define how it is exposed, from
>> subsequent capability related discussions those would probably have to
>> be child resources.
>>
>> In XML terms it would be something like: -
>>
>> <native-interface sasl-authentication="...">
>>        <remoting />
>>        <direct socket-binding="..." />
>>        <http-upgrade use-http-binding="..." undertow-listener="..." />
>> </native-interface>
>> <http-interface http-authentication="...">
>>        <direct http-socket-binding="..." https-socket-binding="..."/>
>>        <undertow-listener name="..." context="/management" />
>> </http-interface>
>>
>> Names chosen were just to illustrate the hierarchy but general principal
>> was the parent is what is exposed, the child is how it is exposed.
>
> Assuming that we are still planning following through with moving
> everything into subsystems/enabling HC subsystems like we discussed last
> January, and given cap/req, shouldn't we seriously consider making it
> something more closely approximating this:
>
> <subsystem xmlns="...remoting...">
>       <endpoint id="management" name="${jboss.node.name}-management">
>           <http-connector name="blah" sasl-authentication="rem-sasl"
> connector-ref="mgmt-connect" .../>
>       </endpoint>
> </subsystem>
> <subsystem xmlns="...network...">
>       <interface name="management">
>           <inet-address value="127.0.0.1"/>
>       </interface>
>       <socket-binding-group name="standard-sockets">
>           <socket-binding name="management-http" interface="management"
> port="${jboss.management.http.port:9990}"/>
>           <socket-binding name="management-https" interface="management"
> port="${jboss.management.https.port:9993}"/>
>           ...boring stuff here...
>       </socket-binding-group>
> </subsystem>
> <subsystem xmlns="...sec-elytron...">
>       <security-domain name="main-domain">
>           <sasl-authentication name="rem-sasl">
>               ...boring stuff here...
>           </sasl-authentication>
>           ...boring realm stuff here...
>       </security-domain>
> </subsystem>
> <subsystem xmlns="...undertow...">
>       <server name="mgmt-server">
>           <http-listener name="default" socket-binding="management-http"
> .../>
>           ...boring stuff here...
>       </server>
>       ...boring stuff here...
> </subsystem>
> <subsystem xmlns="...management...">
>       <remoting endpoint="management"/>     // this is an attribute, not
> a sub-resource
>       <security-domain name="main-domain"/> // this is an attribute, not
> a sub-resource
>       ...boring stuff here...
> </subsystem>
>
> That said if we're not making the move to subsystems, I guess I don't
> really care how it's all laid out too much, but using cap/req whenever
> possible will make any such future move go more smoothly, IMO.
>

From fjuma at redhat.com  Thu Sep 17 10:57:33 2015
From: fjuma at redhat.com (Farah Juma)
Date: Thu, 17 Sep 2015 10:57:33 -0400 (EDT)
Subject: [wildfly-dev] WildFly 10 CR1 is now on OpenShift
In-Reply-To: <551601050.18115495.1442500411463.JavaMail.zimbra@redhat.com>
Message-ID: <1094614893.18126814.1442501853339.JavaMail.zimbra@redhat.com>

See https://github.com/openshift-cartridges/openshift-wildfly-cartridge/tree/wildfly-10 to get started.


From brian.stansberry at redhat.com  Thu Sep 17 11:24:57 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 17 Sep 2015 10:24:57 -0500
Subject: [wildfly-dev] Redesigning http-upgrade configuration for
 management
In-Reply-To: <55FA8FB9.1060706@jboss.com>
References: <55F9A7DD.9050504@redhat.com> <55FA8FB9.1060706@jboss.com>
Message-ID: <55FADB49.3080007@redhat.com>

On 9/17/15 5:02 AM, Darran Lofthouse wrote:
> Has this code been already written or not?  I was told the other day
> that this code was almost complete but now it is back to a design
> discussion.  I have also been told that this is not urgent for WildFly 10.
>
> If this is still being designed and is not critical for WildFly 10 can I
> please ask that this is stopped and we pick this up later - this
> directly conflicts with changes I have already made to integrate Elytron.
>
> In general my opinion is that instead of spending any effort on
> redesigning the current interfaces we should put the effort into the
> design of a new subsystem to contain these interfaces and that should
> start from the beginning where we can remodel the relationship between
> the two interface types.
>

That is fine; we should stop. This work was driven by 
https://issues.jboss.org/browse/WFCORE-949 / 
https://issues.jboss.org/browse/JBEAP-980 neither of which are scheduled 
for WF 10. WFCORE-949 isn't truly a regression, as doing a similar thing 
in EAP 6 by removing the native interface will also fail. But still, if 
we could have fixed 949 for WF 10 by adding a no-brainer child resource 
I would have liked to do so.

But it's clear that the design of that child resource is not a 
no-brainer, so we should stop.

> Regards,
> Darran Lofthouse.
>
>
> On 16/09/15 18:33, Emmanuel Hugonnet wrote:
>> Hi,
>> This is for management interfaces only.
>> We need a capability to cover the fact that some management interfaces may provides jboss-remoting endpoints to be used by JMX.
>> The native-interface provides this capability at the resource level, so this is nice and straightforward.
>> Currently making an http-interface http-upgrade-enabled is done through the well named 'http-upgrade-enabled' attribute.
>> But because of the use of an attribute we have no nice standard way to register the capability.
>> One way to do that would be to use a child resource, "http-upgrade-support=on" to define the fact that this http-interface supports upgrade.
>> We could then move the code and services associated with this support to the addHandler and removeHandler.
>> To keep backward compatibility :
>>    - for the add / remove of current resource :
>> it is easy to add a new step to add the new resource on the http-interface addHandler, and do the same for removal.
>>    - for the beloved http-upgrade-enabled attribute which is writeable but doesn't really do anything until the interface is restarted.
>> Of course it could get deprecated but we would still have a writeable attribute that represents a duplicate state of the child resource.
>> We may want to use the write-attribute handler on this attribute to call the resource ops without impacting the services, just changing the
>> model.
>>
>> What do you think ?
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From brian.stansberry at redhat.com  Thu Sep 17 11:40:45 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 17 Sep 2015 10:40:45 -0500
Subject: [wildfly-dev] Redesigning http-upgrade configuration for
 management
In-Reply-To: <55FA728C.2080803@redhat.com>
References: <55F9A7DD.9050504@redhat.com> <55F9B0D3.5080008@redhat.com>
	<55FA728C.2080803@redhat.com>
Message-ID: <55FADEFD.3040605@redhat.com>

On 9/17/15 2:58 AM, Emmanuel Hugonnet wrote:
>
>
> Le 16/09/2015 20:11, Brian Stansberry a ?crit :
>> On 9/16/15 12:33 PM, Emmanuel Hugonnet wrote:
>>> Hi,
>>> This is for management interfaces only.
>>> We need a capability to cover the fact that some management interfaces may provides jboss-remoting endpoints to be used by JMX.
>>> The native-interface provides this capability at the resource level, so this is nice and straightforward.
>>> Currently making an http-interface http-upgrade-enabled is done through the well named 'http-upgrade-enabled' attribute.
>>> But because of the use of an attribute we have no nice standard way to register the capability.
>>> One way to do that would be to use a child resource, "http-upgrade-support=on" to define the fact that this http-interface supports upgrade.
>>
>> We need a different name for this. Address elements should be of the
>> form category=specific_name.
>>
>> This resource is the logical encapsulation of some sort of
>> functionality. So we need to brainstorm and define what exactly that
>> functionality is and what it may become and then hopefully the name for
>> the resource will fall out of that.
>>
>> For example, I believe http-upgrade is an implementation detail. What
>> the resource is really about is providing JBoss Remoting-based
>> management in an HTTP environment. We refer to that elsewhere as
>> "native" (i.e. in
>> /core-service=management/management-interface=native-interface) So is
>> this resource primarily about native management?
>
> I agree so something along 'native-support=on'.
>

This is a resource, not an attribute. The existence of the resource 
itself implies "on".

Resources should have a name following a pattern like 
"category_of_the_thing=specific_name_of_the_thing".

There are some cases where the resource is a singleton and 
"category_of_the_thing" becomes kind of pointless, so we use generic 
terms like 'service' or 'configuration' in that part. But we still 
follow the pattern. It's not clear though that this is even that kind of 
case. A key goal of an API design discussion like this is to identify 
the key characteristics of the thing in question and then decide if 
there's a meaningful "category_of_the_thing" into which other resources 
may fall.

>
>>
>>> We could then move the code and services associated with this support to the addHandler and removeHandler.
>>> To keep backward compatibility :
>>>    - for the add / remove of current resource :
>>> it is easy to add a new step to add the new resource on the http-interface addHandler, and do the same for removal.
>>
>> The removal should require reload, to encourage the user to understand
>> that they may lose their connection to the server, and to avoid creating
>> another situation where executing an op can result in an unclean
>> execution from the client's point of view due to the connection closing.
>
> Yes of course
>
>>
>>>    - for the beloved http-upgrade-enabled attribute which is writeable but doesn't really do anything until the interface is restarted.
>>> Of course it could get deprecated but we would still have a writeable attribute that represents a duplicate state of the child resource.
>>> We may want to use the write-attribute handler on this attribute to call the resource ops without impacting the services, just changing the
>>> model.
>>
>> If they set the value to 'false', yes. If they set it to true, putting
>> the server into reload required is enough, as the boot handling should
>> be adding the child resource when http-upgrade-enabled is 'true'.
>>
>>>
>>> What do you think ?
>>>
>>
>> There's the fact that http-upgrade-enabled currently supports
>> expressions. We need to define all the semantics around that. Some thoughts:
>>
>> 1) If the user stores the expression value in the vault, that just can't
>> work, as the evaluation of the expression in order to decide whether to
>> add the child resource has to happen before the vault is available. I
>> have no problem with that constraint, since using a vault expression
>> here would be a real corner case. And this attribute has never been in
>> EAP where we might have a greater requirement to continue to support old
>> weird corner cases.
>>
>> 2) If the value doesn't have an expression, we can drop the attribute
>> when marshaling, and just write the child element. But if it does have
>> an expression we have to marshal the attribute back to xml.
>> Unfortunately this precludes dropping the attribute from the current
>> version of the xsd. :(
>
> Yes and in the model itself
>
>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From iamutkarshtiwari at gmail.com  Fri Sep 18 03:14:06 2015
From: iamutkarshtiwari at gmail.com (Utkarsh Tiwari)
Date: Fri, 18 Sep 2015 12:44:06 +0530
Subject: [wildfly-dev] Want to contribute
Message-ID: <CAFRUKod7Ai-LYY_T=e0skQgMkamjNXUJo9um66w6maVUXKKQ=Q@mail.gmail.com>

Hello!
         I would like to contribute to Jboss community.I know familiar with
Java. Could anyone here help me get started?

regards-
Utkarsh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150918/a12864d1/attachment.html 

From hbraun at redhat.com  Fri Sep 18 03:24:16 2015
From: hbraun at redhat.com (Heiko Braun)
Date: Fri, 18 Sep 2015 09:24:16 +0200
Subject: [wildfly-dev] Want to contribute
In-Reply-To: <CAFRUKod7Ai-LYY_T=e0skQgMkamjNXUJo9um66w6maVUXKKQ=Q@mail.gmail.com>
References: <CAFRUKod7Ai-LYY_T=e0skQgMkamjNXUJo9um66w6maVUXKKQ=Q@mail.gmail.com>
Message-ID: <0EC31292-DBA5-467C-98A4-B21F54AC389A@redhat.com>

http://www.jboss.org/get-involved/ <http://www.jboss.org/get-involved/>


> On 18 Sep 2015, at 09:14, Utkarsh Tiwari <iamutkarshtiwari at gmail.com> wrote:
> 
> Hello! 
>          I would like to contribute to Jboss community.I know familiar with Java. Could anyone here help me get started?
> 
> regards-
> Utkarsh
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150918/45f6daef/attachment.html 

From tomaz.cerar at gmail.com  Fri Sep 18 04:38:20 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 18 Sep 2015 10:38:20 +0200
Subject: [wildfly-dev] Want to contribute
In-Reply-To: <CAFRUKod7Ai-LYY_T=e0skQgMkamjNXUJo9um66w6maVUXKKQ=Q@mail.gmail.com>
References: <CAFRUKod7Ai-LYY_T=e0skQgMkamjNXUJo9um66w6maVUXKKQ=Q@mail.gmail.com>
Message-ID: <CAMquZP7KtDhzfevFF6VXKcodC00rGO9q0=BDP5z7QSqvxWenvg@mail.gmail.com>

Also if you are thinking about contributing to WildFly,
see https://developer.jboss.org/wiki/HackingOnWildFly
and
https://developer.jboss.org/wiki/WildFlyPullRequestStandardsAndGuidelines

On Fri, Sep 18, 2015 at 9:14 AM, Utkarsh Tiwari <iamutkarshtiwari at gmail.com>
wrote:

> Hello!
>          I would like to contribute to Jboss community.I know familiar
> with Java. Could anyone here help me get started?
>
> regards-
> Utkarsh
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150918/c6e75d49/attachment-0001.html 

From david.lloyd at redhat.com  Fri Sep 18 09:18:43 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 18 Sep 2015 08:18:43 -0500
Subject: [wildfly-dev] Capabilities/requirements and deployments
Message-ID: <55FC0F33.5050500@redhat.com>

While working on moving the EJB subsystem to support Elytron, I 
encountered a dilemma regarding cap/req.

Elytron exposes security domains as capabilities.  EJB deployments have 
the ability to specify which security domain is used for authorization 
purposes.  This specification is by name.

The dilemma is:

1) Allow EJB deployments to directly reference security domain names, 
thus implicitly causing the EJB subsystem to require all or none of the 
security domains that are or could be configured
2) Require the EJB subsystem to declare (in the model) what security 
domains it uses, thus requiring only security domains that are used

Option 1 seems disadvantageous because if EJB requires no domains, it is 
possible to break deployments without getting so much as a warning, but 
if it requires all, then you can never make significant changes to your 
security domain configuration.

Option 2 requires an extra level of configuration, but on the other 
hand, it also allows tricks like providing a "local" name for each 
security domain which the deployment can reference, which grants a small 
but potentially useful degree of flexibility, and it has a better degree 
of in-model referential integrity.

Option 2 also requires that any run-time operation to remove a security 
domain from the EJB subsystem be verified against current deployments. 
I wonder if we can do this with runtime-only resources and cap/req too?

I guess I've just talked myself into Option 2, but I'm thinking that 
this is not going to be the only case like this as we further develop 
cap/req-enabled subsystems.

Thoughts?
-- 
- DML

From jason.greene at redhat.com  Fri Sep 18 09:31:39 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Fri, 18 Sep 2015 09:31:39 -0400 (EDT)
Subject: [wildfly-dev] Capabilities/requirements and deployments
In-Reply-To: <55FC0F33.5050500@redhat.com>
References: <55FC0F33.5050500@redhat.com>
Message-ID: <6C135D23-7182-453A-8D9F-ECAB73BFD287@redhat.com>

Why not use optional capabilities? That would more closely match old behavior.

> On Sep 18, 2015, at 8:19 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> While working on moving the EJB subsystem to support Elytron, I 
> encountered a dilemma regarding cap/req.
> 
> Elytron exposes security domains as capabilities.  EJB deployments have 
> the ability to specify which security domain is used for authorization 
> purposes.  This specification is by name.
> 
> The dilemma is:
> 
> 1) Allow EJB deployments to directly reference security domain names, 
> thus implicitly causing the EJB subsystem to require all or none of the 
> security domains that are or could be configured
> 2) Require the EJB subsystem to declare (in the model) what security 
> domains it uses, thus requiring only security domains that are used
> 
> Option 1 seems disadvantageous because if EJB requires no domains, it is 
> possible to break deployments without getting so much as a warning, but 
> if it requires all, then you can never make significant changes to your 
> security domain configuration.
> 
> Option 2 requires an extra level of configuration, but on the other 
> hand, it also allows tricks like providing a "local" name for each 
> security domain which the deployment can reference, which grants a small 
> but potentially useful degree of flexibility, and it has a better degree 
> of in-model referential integrity.
> 
> Option 2 also requires that any run-time operation to remove a security 
> domain from the EJB subsystem be verified against current deployments. 
> I wonder if we can do this with runtime-only resources and cap/req too?
> 
> I guess I've just talked myself into Option 2, but I'm thinking that 
> this is not going to be the only case like this as we further develop 
> cap/req-enabled subsystems.
> 
> Thoughts?
> -- 
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From david.lloyd at redhat.com  Fri Sep 18 09:36:01 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 18 Sep 2015 08:36:01 -0500
Subject: [wildfly-dev] Capabilities/requirements and deployments
In-Reply-To: <6C135D23-7182-453A-8D9F-ECAB73BFD287@redhat.com>
References: <55FC0F33.5050500@redhat.com>
	<6C135D23-7182-453A-8D9F-ECAB73BFD287@redhat.com>
Message-ID: <55FC1341.8070705@redhat.com>

I don't like this because if a domain is removed at runtime, it could 
have unpredictable effects.  I'd rather force the model to stay 
consistent whenever we can.

On 09/18/2015 08:31 AM, Jason T. Greene wrote:
> Why not use optional capabilities? That would more closely match old behavior.
>
>> On Sep 18, 2015, at 8:19 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>
>> While working on moving the EJB subsystem to support Elytron, I
>> encountered a dilemma regarding cap/req.
>>
>> Elytron exposes security domains as capabilities.  EJB deployments have
>> the ability to specify which security domain is used for authorization
>> purposes.  This specification is by name.
>>
>> The dilemma is:
>>
>> 1) Allow EJB deployments to directly reference security domain names,
>> thus implicitly causing the EJB subsystem to require all or none of the
>> security domains that are or could be configured
>> 2) Require the EJB subsystem to declare (in the model) what security
>> domains it uses, thus requiring only security domains that are used
>>
>> Option 1 seems disadvantageous because if EJB requires no domains, it is
>> possible to break deployments without getting so much as a warning, but
>> if it requires all, then you can never make significant changes to your
>> security domain configuration.
>>
>> Option 2 requires an extra level of configuration, but on the other
>> hand, it also allows tricks like providing a "local" name for each
>> security domain which the deployment can reference, which grants a small
>> but potentially useful degree of flexibility, and it has a better degree
>> of in-model referential integrity.
>>
>> Option 2 also requires that any run-time operation to remove a security
>> domain from the EJB subsystem be verified against current deployments.
>> I wonder if we can do this with runtime-only resources and cap/req too?
>>
>> I guess I've just talked myself into Option 2, but I'm thinking that
>> this is not going to be the only case like this as we further develop
>> cap/req-enabled subsystems.
>>
>> Thoughts?
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
- DML

From jason.greene at redhat.com  Fri Sep 18 09:38:07 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Fri, 18 Sep 2015 09:38:07 -0400 (EDT)
Subject: [wildfly-dev] Capabilities/requirements and deployments
In-Reply-To: <55FC1341.8070705@redhat.com>
References: <55FC0F33.5050500@redhat.com>
	<6C135D23-7182-453A-8D9F-ECAB73BFD287@redhat.com>
	<55FC1341.8070705@redhat.com>
Message-ID: <1199C231-2BA1-42C6-BBBD-B75618FAABC6@redhat.com>

If that happened it would down the deployment because capabilities are translated to hard service deps 

Sent from my iPhone

> On Sep 18, 2015, at 8:36 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> I don't like this because if a domain is removed at runtime, it could have unpredictable effects.  I'd rather force the model to stay consistent whenever we can.
> 
>> On 09/18/2015 08:31 AM, Jason T. Greene wrote:
>> Why not use optional capabilities? That would more closely match old behavior.
>> 
>>> On Sep 18, 2015, at 8:19 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>> 
>>> While working on moving the EJB subsystem to support Elytron, I
>>> encountered a dilemma regarding cap/req.
>>> 
>>> Elytron exposes security domains as capabilities.  EJB deployments have
>>> the ability to specify which security domain is used for authorization
>>> purposes.  This specification is by name.
>>> 
>>> The dilemma is:
>>> 
>>> 1) Allow EJB deployments to directly reference security domain names,
>>> thus implicitly causing the EJB subsystem to require all or none of the
>>> security domains that are or could be configured
>>> 2) Require the EJB subsystem to declare (in the model) what security
>>> domains it uses, thus requiring only security domains that are used
>>> 
>>> Option 1 seems disadvantageous because if EJB requires no domains, it is
>>> possible to break deployments without getting so much as a warning, but
>>> if it requires all, then you can never make significant changes to your
>>> security domain configuration.
>>> 
>>> Option 2 requires an extra level of configuration, but on the other
>>> hand, it also allows tricks like providing a "local" name for each
>>> security domain which the deployment can reference, which grants a small
>>> but potentially useful degree of flexibility, and it has a better degree
>>> of in-model referential integrity.
>>> 
>>> Option 2 also requires that any run-time operation to remove a security
>>> domain from the EJB subsystem be verified against current deployments.
>>> I wonder if we can do this with runtime-only resources and cap/req too?
>>> 
>>> I guess I've just talked myself into Option 2, but I'm thinking that
>>> this is not going to be the only case like this as we further develop
>>> cap/req-enabled subsystems.
>>> 
>>> Thoughts?
>>> --
>>> - DML
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> -- 
> - DML


From david.lloyd at redhat.com  Fri Sep 18 09:43:10 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Fri, 18 Sep 2015 08:43:10 -0500
Subject: [wildfly-dev] Capabilities/requirements and deployments
In-Reply-To: <1199C231-2BA1-42C6-BBBD-B75618FAABC6@redhat.com>
References: <55FC0F33.5050500@redhat.com>
	<6C135D23-7182-453A-8D9F-ECAB73BFD287@redhat.com>
	<55FC1341.8070705@redhat.com>
	<1199C231-2BA1-42C6-BBBD-B75618FAABC6@redhat.com>
Message-ID: <55FC14EE.6020608@redhat.com>

Fair enough.  In terms of cap/req though - if this is the desired 
behavior, it would almost be better to just have no requirement at all. 
  But anything that does any detection (now or in the future) like "hey 
is anything using this resource?" will return a false negative if it's 
used by a deployment.  If we went the other way and had an optional 
requirement on all security domains, we'd need some hook to 
automatically add new requirements every time a domain was added. 
Either way seems not so good to me... maybe there's another approach though?

On 09/18/2015 08:38 AM, Jason T. Greene wrote:
> If that happened it would down the deployment because capabilities are translated to hard service deps
>
> Sent from my iPhone
>
>> On Sep 18, 2015, at 8:36 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>
>> I don't like this because if a domain is removed at runtime, it could have unpredictable effects.  I'd rather force the model to stay consistent whenever we can.
>>
>>> On 09/18/2015 08:31 AM, Jason T. Greene wrote:
>>> Why not use optional capabilities? That would more closely match old behavior.
>>>
>>>> On Sep 18, 2015, at 8:19 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>>>
>>>> While working on moving the EJB subsystem to support Elytron, I
>>>> encountered a dilemma regarding cap/req.
>>>>
>>>> Elytron exposes security domains as capabilities.  EJB deployments have
>>>> the ability to specify which security domain is used for authorization
>>>> purposes.  This specification is by name.
>>>>
>>>> The dilemma is:
>>>>
>>>> 1) Allow EJB deployments to directly reference security domain names,
>>>> thus implicitly causing the EJB subsystem to require all or none of the
>>>> security domains that are or could be configured
>>>> 2) Require the EJB subsystem to declare (in the model) what security
>>>> domains it uses, thus requiring only security domains that are used
>>>>
>>>> Option 1 seems disadvantageous because if EJB requires no domains, it is
>>>> possible to break deployments without getting so much as a warning, but
>>>> if it requires all, then you can never make significant changes to your
>>>> security domain configuration.
>>>>
>>>> Option 2 requires an extra level of configuration, but on the other
>>>> hand, it also allows tricks like providing a "local" name for each
>>>> security domain which the deployment can reference, which grants a small
>>>> but potentially useful degree of flexibility, and it has a better degree
>>>> of in-model referential integrity.
>>>>
>>>> Option 2 also requires that any run-time operation to remove a security
>>>> domain from the EJB subsystem be verified against current deployments.
>>>> I wonder if we can do this with runtime-only resources and cap/req too?
>>>>
>>>> I guess I've just talked myself into Option 2, but I'm thinking that
>>>> this is not going to be the only case like this as we further develop
>>>> cap/req-enabled subsystems.
>>>>
>>>> Thoughts?
>>>> --
>>>> - DML
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> --
>> - DML

-- 
- DML

From jason.greene at redhat.com  Fri Sep 18 10:09:42 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Fri, 18 Sep 2015 10:09:42 -0400 (EDT)
Subject: [wildfly-dev] Capabilities/requirements and deployments
In-Reply-To: <55FC14EE.6020608@redhat.com>
References: <55FC0F33.5050500@redhat.com>
	<6C135D23-7182-453A-8D9F-ECAB73BFD287@redhat.com>
	<55FC1341.8070705@redhat.com>
	<1199C231-2BA1-42C6-BBBD-B75618FAABC6@redhat.com>
	<55FC14EE.6020608@redhat.com>
Message-ID: <0AAF680A-8980-4792-9074-ADE2AEE1DB50@redhat.com>

Yeah TBH I have always wondered if the ability to reference a non existent security domain, and the fallback to a default policy is a good thing.


> On Sep 18, 2015, at 8:43 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> Fair enough.  In terms of cap/req though - if this is the desired behavior, it would almost be better to just have no requirement at all.  But anything that does any detection (now or in the future) like "hey is anything using this resource?" will return a false negative if it's used by a deployment.  If we went the other way and had an optional requirement on all security domains, we'd need some hook to automatically add new requirements every time a domain was added. Either way seems not so good to me... maybe there's another approach though?
> 
>> On 09/18/2015 08:38 AM, Jason T. Greene wrote:
>> If that happened it would down the deployment because capabilities are translated to hard service deps
>> 
>> Sent from my iPhone
>> 
>>> On Sep 18, 2015, at 8:36 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>> 
>>> I don't like this because if a domain is removed at runtime, it could have unpredictable effects.  I'd rather force the model to stay consistent whenever we can.
>>> 
>>>> On 09/18/2015 08:31 AM, Jason T. Greene wrote:
>>>> Why not use optional capabilities? That would more closely match old behavior.
>>>> 
>>>>> On Sep 18, 2015, at 8:19 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>>>> 
>>>>> While working on moving the EJB subsystem to support Elytron, I
>>>>> encountered a dilemma regarding cap/req.
>>>>> 
>>>>> Elytron exposes security domains as capabilities.  EJB deployments have
>>>>> the ability to specify which security domain is used for authorization
>>>>> purposes.  This specification is by name.
>>>>> 
>>>>> The dilemma is:
>>>>> 
>>>>> 1) Allow EJB deployments to directly reference security domain names,
>>>>> thus implicitly causing the EJB subsystem to require all or none of the
>>>>> security domains that are or could be configured
>>>>> 2) Require the EJB subsystem to declare (in the model) what security
>>>>> domains it uses, thus requiring only security domains that are used
>>>>> 
>>>>> Option 1 seems disadvantageous because if EJB requires no domains, it is
>>>>> possible to break deployments without getting so much as a warning, but
>>>>> if it requires all, then you can never make significant changes to your
>>>>> security domain configuration.
>>>>> 
>>>>> Option 2 requires an extra level of configuration, but on the other
>>>>> hand, it also allows tricks like providing a "local" name for each
>>>>> security domain which the deployment can reference, which grants a small
>>>>> but potentially useful degree of flexibility, and it has a better degree
>>>>> of in-model referential integrity.
>>>>> 
>>>>> Option 2 also requires that any run-time operation to remove a security
>>>>> domain from the EJB subsystem be verified against current deployments.
>>>>> I wonder if we can do this with runtime-only resources and cap/req too?
>>>>> 
>>>>> I guess I've just talked myself into Option 2, but I'm thinking that
>>>>> this is not going to be the only case like this as we further develop
>>>>> cap/req-enabled subsystems.
>>>>> 
>>>>> Thoughts?
>>>>> --
>>>>> - DML
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> 
>>> --
>>> - DML
> 
> -- 
> - DML


From jason.greene at redhat.com  Fri Sep 18 10:16:29 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Fri, 18 Sep 2015 10:16:29 -0400 (EDT)
Subject: [wildfly-dev] Capabilities/requirements and deployments
In-Reply-To: <0AAF680A-8980-4792-9074-ADE2AEE1DB50@redhat.com>
References: <55FC0F33.5050500@redhat.com>
	<6C135D23-7182-453A-8D9F-ECAB73BFD287@redhat.com>
	<55FC1341.8070705@redhat.com>
	<1199C231-2BA1-42C6-BBBD-B75618FAABC6@redhat.com>
	<55FC14EE.6020608@redhat.com>
	<0AAF680A-8980-4792-9074-ADE2AEE1DB50@redhat.com>
Message-ID: <8256C200-A90C-4EE9-BEA7-CB4DAE7ABFB0@redhat.com>

Just a small point of clarification, if you optionally use a capability part of using it allows that you register a requirement. So the behavior is essentially that if you have the capability the deployment will use it and register a requirement if you don't have the capability there will be no requirements registered

Sent from my iPhone

> On Sep 18, 2015, at 9:11 AM, Jason T. Greene <jason.greene at redhat.com> wrote:
> 
> Yeah TBH I have always wondered if the ability to reference a non existent security domain, and the fallback to a default policy is a good thing.
> 
> 
>> On Sep 18, 2015, at 8:43 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> 
>> Fair enough.  In terms of cap/req though - if this is the desired behavior, it would almost be better to just have no requirement at all.  But anything that does any detection (now or in the future) like "hey is anything using this resource?" will return a false negative if it's used by a deployment.  If we went the other way and had an optional requirement on all security domains, we'd need some hook to automatically add new requirements every time a domain was added. Either way seems not so good to me... maybe there's another approach though?
>> 
>>> On 09/18/2015 08:38 AM, Jason T. Greene wrote:
>>> If that happened it would down the deployment because capabilities are translated to hard service deps
>>> 
>>> Sent from my iPhone
>>> 
>>>> On Sep 18, 2015, at 8:36 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>>> 
>>>> I don't like this because if a domain is removed at runtime, it could have unpredictable effects.  I'd rather force the model to stay consistent whenever we can.
>>>> 
>>>>> On 09/18/2015 08:31 AM, Jason T. Greene wrote:
>>>>> Why not use optional capabilities? That would more closely match old behavior.
>>>>> 
>>>>>> On Sep 18, 2015, at 8:19 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>>>>> 
>>>>>> While working on moving the EJB subsystem to support Elytron, I
>>>>>> encountered a dilemma regarding cap/req.
>>>>>> 
>>>>>> Elytron exposes security domains as capabilities.  EJB deployments have
>>>>>> the ability to specify which security domain is used for authorization
>>>>>> purposes.  This specification is by name.
>>>>>> 
>>>>>> The dilemma is:
>>>>>> 
>>>>>> 1) Allow EJB deployments to directly reference security domain names,
>>>>>> thus implicitly causing the EJB subsystem to require all or none of the
>>>>>> security domains that are or could be configured
>>>>>> 2) Require the EJB subsystem to declare (in the model) what security
>>>>>> domains it uses, thus requiring only security domains that are used
>>>>>> 
>>>>>> Option 1 seems disadvantageous because if EJB requires no domains, it is
>>>>>> possible to break deployments without getting so much as a warning, but
>>>>>> if it requires all, then you can never make significant changes to your
>>>>>> security domain configuration.
>>>>>> 
>>>>>> Option 2 requires an extra level of configuration, but on the other
>>>>>> hand, it also allows tricks like providing a "local" name for each
>>>>>> security domain which the deployment can reference, which grants a small
>>>>>> but potentially useful degree of flexibility, and it has a better degree
>>>>>> of in-model referential integrity.
>>>>>> 
>>>>>> Option 2 also requires that any run-time operation to remove a security
>>>>>> domain from the EJB subsystem be verified against current deployments.
>>>>>> I wonder if we can do this with runtime-only resources and cap/req too?
>>>>>> 
>>>>>> I guess I've just talked myself into Option 2, but I'm thinking that
>>>>>> this is not going to be the only case like this as we further develop
>>>>>> cap/req-enabled subsystems.
>>>>>> 
>>>>>> Thoughts?
>>>>>> --
>>>>>> - DML
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> 
>>>> --
>>>> - DML
>> 
>> -- 
>> - DML
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From hpehl at redhat.com  Mon Sep 21 05:47:54 2015
From: hpehl at redhat.com (Harald Pehl)
Date: Mon, 21 Sep 2015 11:47:54 +0200
Subject: [wildfly-dev] WildFly - encrypt datasource.
In-Reply-To: <CAJ6L+YGQ-W=HT6_cQ5Q3nd6R9goWpbMNC-BGB1+F9mJSrAD9pA@mail.gmail.com>
References: <CAJ6L+YGQ-W=HT6_cQ5Q3nd6R9goWpbMNC-BGB1+F9mJSrAD9pA@mail.gmail.com>
Message-ID: <72E823CC-2588-4725-813D-532A89D5247B@redhat.com>

Yes this is something we'd like to support in a future release. Since there will be a lot of changes on how to configure security with the introduction of Elytron, we?d like to postpone this feature until Elytron has been fully integrated in WildFly. 

.: Harald

> Am 14.09.2015 um 19:38 schrieb Eduardo Medeiros <eduardo at dotmac.com.br>:
> 
> Hello Guys,
> 
> I would like to know if there is a road map to add a feature for encrypt password from data sources using HAL console.
> 
> Nowadays, I know that this configuration is possible using the keytool and vault.sh, but is a little bit hard and confused.
> 
> --
> Thank you,
> Eduardo Medeiros.
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

---
Harald Pehl
JBoss by Red Hat
http://hpehl.info



From darran.lofthouse at jboss.com  Mon Sep 21 09:52:01 2015
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Mon, 21 Sep 2015 14:52:01 +0100
Subject: [wildfly-dev] WildFly - encrypt datasource.
In-Reply-To: <72E823CC-2588-4725-813D-532A89D5247B@redhat.com>
References: <CAJ6L+YGQ-W=HT6_cQ5Q3nd6R9goWpbMNC-BGB1+F9mJSrAD9pA@mail.gmail.com>
	<72E823CC-2588-4725-813D-532A89D5247B@redhat.com>
Message-ID: <56000B81.80005@jboss.com>

+1

In addition to any back end operations needed to actually be able to 
pass in plain text passwords and have then stored in the vault we also 
have to consider how we transfer the passwords from the client side 
without opening up the opportunity for them to be intercepted.

Regarding complexity of working with the vault I would also like to 
explore options so that once the vault is configured we automate the 
interactions with it e.g. an end user would just create a datasource 
with the password in plain text, we then handle storing it in the vault 
and update the model to reference the stored value.

On 21/09/15 10:47, Harald Pehl wrote:
> Yes this is something we'd like to support in a future release. Since there will be a lot of changes on how to configure security with the introduction of Elytron, we?d like to postpone this feature until Elytron has been fully integrated in WildFly.
>
> .: Harald
>
>> Am 14.09.2015 um 19:38 schrieb Eduardo Medeiros <eduardo at dotmac.com.br>:
>>
>> Hello Guys,
>>
>> I would like to know if there is a road map to add a feature for encrypt password from data sources using HAL console.
>>
>> Nowadays, I know that this configuration is possible using the keytool and vault.sh, but is a little bit hard and confused.
>>
>> --
>> Thank you,
>> Eduardo Medeiros.
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> ---
> Harald Pehl
> JBoss by Red Hat
> http://hpehl.info
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From alex_orl1079 at yahoo.it  Tue Sep 22 18:33:21 2015
From: alex_orl1079 at yahoo.it (alex orl)
Date: Tue, 22 Sep 2015 22:33:21 +0000 (UTC)
Subject: [wildfly-dev] jersey custom annotation injection
Message-ID: <171819066.2614857.1442961201055.JavaMail.yahoo@mail.yahoo.com>

I m using Wildfly 9.0 and i need to build my custom annotation injection mechanism in order to inject my principal object.. My requirement is to work with Jersey 2.x.So i'm following the jersey reference guide at this link:
https://jersey.java.net/documentation/latest/ioc.html

But unluckily my injected principal object is always null. Someone asserts that is an inevitable conflict between the resteasy jax rs implementation embedded with wildfly and Jersey.So what the way to make jersey hk2 injection to work without conflicting with the wildfly weld?
Is there a way to implement the same custom injection with resteasy?thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150922/c6f0eaff/attachment.html 

From arjan.tijms at gmail.com  Wed Sep 23 09:31:17 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 23 Sep 2015 15:31:17 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
	request#authenticate does nothing now
Message-ID: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>

Hi,

It looks like that after WFLY-5298 (this commit specifically
https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6)
HttpServletRequest#authenticate does not longer do anything.

HttpServletRequest#authenticate calls though to
JASPIAuthenticationMechanism#authenticate.

There it now obtains the attachment that was set by the new
JASPICInitialHandler, which calls the SAM at the beginning of the
request. And then uses the stored "isValid" outcome directly, without
calling the SAM again.

See the code below:

  public AuthenticationMechanismOutcome authenticate(final
HttpServerExchange exchange, final SecurityContext sc) {
        JASPICAttachment attachment =
exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);

        AuthenticationMechanismOutcome outcome;
        Account authenticatedAccount = null;

        boolean isValid = attachment.isValid();
        final ServletRequestContext requestContext =
attachment.getRequestContext();
        final JASPIServerAuthenticationManager sam = attachment.getSam();
        final JASPICallbackHandler cbh = attachment.getCbh();

        GenericMessageInfo messageInfo = attachment.getMessageInfo();
        if (isValid) {
            // The CBH filled in the JBOSS SecurityContext, we need to
create an Undertow account based on that
            org.jboss.security.SecurityContext jbossSct =
SecurityActions.getSecurityContext();
            authenticatedAccount =
createAccount(attachment.getCachedAccount(), jbossSct);
        }

This is not correct I think. The code should call the SAM once again
and use the outcome from that call.

Am I missing something, or was the new call to the SAM simply
forgotten at this point?

Kind regards,
Arjan Tijms

From arjan.tijms at gmail.com  Wed Sep 23 11:58:56 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 23 Sep 2015 17:58:56 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
	request#authenticate does nothing now
In-Reply-To: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
Message-ID: <CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>

p.s. if I just revert JASPIAuthenticationMechanism to the previous
version, but leaving in the new JASPICInitialHandler, then everything
seems to work again. This is a bit of hacky workaround perhaps, but in
some quick testing it does do the trick.

On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
> Hi,
>
> It looks like that after WFLY-5298 (this commit specifically
> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6)
> HttpServletRequest#authenticate does not longer do anything.
>
> HttpServletRequest#authenticate calls though to
> JASPIAuthenticationMechanism#authenticate.
>
> There it now obtains the attachment that was set by the new
> JASPICInitialHandler, which calls the SAM at the beginning of the
> request. And then uses the stored "isValid" outcome directly, without
> calling the SAM again.
>
> See the code below:
>
>   public AuthenticationMechanismOutcome authenticate(final
> HttpServerExchange exchange, final SecurityContext sc) {
>         JASPICAttachment attachment =
> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>
>         AuthenticationMechanismOutcome outcome;
>         Account authenticatedAccount = null;
>
>         boolean isValid = attachment.isValid();
>         final ServletRequestContext requestContext =
> attachment.getRequestContext();
>         final JASPIServerAuthenticationManager sam = attachment.getSam();
>         final JASPICallbackHandler cbh = attachment.getCbh();
>
>         GenericMessageInfo messageInfo = attachment.getMessageInfo();
>         if (isValid) {
>             // The CBH filled in the JBOSS SecurityContext, we need to
> create an Undertow account based on that
>             org.jboss.security.SecurityContext jbossSct =
> SecurityActions.getSecurityContext();
>             authenticatedAccount =
> createAccount(attachment.getCachedAccount(), jbossSct);
>         }
>
> This is not correct I think. The code should call the SAM once again
> and use the outcome from that call.
>
> Am I missing something, or was the new call to the SAM simply
> forgotten at this point?
>
> Kind regards,
> Arjan Tijms

From kap4020 at gmail.com  Thu Sep 24 07:08:45 2015
From: kap4020 at gmail.com (Karl Pietrzak)
Date: Thu, 24 Sep 2015 07:08:45 -0400
Subject: [wildfly-dev] recommended library for SAML auth for WF9+?
Message-ID: <CACtdb3+wwtKJHxHLKScGscqji2EudrspQyrGiTiR6L1yrDBj2A@mail.gmail.com>

Hi there, everyone.

With the deprecation of Picketlink, what's the recommended library for SAML
authentication?  It seems Keycloak isn't included in WF9.0.1Final or
WF10.0CR2, but Picketlink still is.  Should we migrate to Spring
Security/Apache Shiro/etc.?

Thoughts?

-- 
Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150924/3f5bf0ea/attachment.html 

From charles at dazen.com.br  Thu Sep 24 07:32:02 2015
From: charles at dazen.com.br (Charles Queiroz)
Date: Thu, 24 Sep 2015 08:32:02 -0300
Subject: [wildfly-dev] recommended library for SAML auth for WF9+?
In-Reply-To: <CACtdb3+wwtKJHxHLKScGscqji2EudrspQyrGiTiR6L1yrDBj2A@mail.gmail.com>
References: <CACtdb3+wwtKJHxHLKScGscqji2EudrspQyrGiTiR6L1yrDBj2A@mail.gmail.com>
Message-ID: <55A1ABB6-4777-4500-AB6F-A631C3DECF4F@dazen.com.br>

HI Karl, 

Why not keycloak? PicketLink and keycloak are merged. I'm using keycloak for this. 

Keycloak is not included, but you can configure easy following the documentation

Best regards,
Charles Queiroz

Dazen?  IT Services
Technology - Software Development 
charles at dazen.com.br
Fortaleza - CE / Brazil
Phone: +55 (85) 9786 8562


> On Sep 24, 2015, at 08:08, Karl Pietrzak <kap4020 at gmail.com> wrote:
> 
> Hi there, everyone.
> 
> With the deprecation of Picketlink, what's the recommended library for SAML authentication?  It seems Keycloak isn't included in WF9.0.1Final or WF10.0CR2, but Picketlink still is.  Should we migrate to Spring Security/Apache Shiro/etc.?
> 
> Thoughts?
> 
> -- 
> Karl
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150924/094fe5e0/attachment.html 

From psotirop at redhat.com  Thu Sep 24 10:41:50 2015
From: psotirop at redhat.com (Panagiotis Sotiropoulos)
Date: Thu, 24 Sep 2015 10:41:50 -0400 (EDT)
Subject: [wildfly-dev] Proposal of an additional JBossThreadPoolExecutor
	(WFLY-5332)
In-Reply-To: <855034116.42607534.1443105252450.JavaMail.zimbra@redhat.com>
References: <855034116.42607534.1443105252450.JavaMail.zimbra@redhat.com>
Message-ID: <1996925021.42617028.1443105710871.JavaMail.zimbra@redhat.com>

Hello all,

Because of WFLY-5332, I have modified the JBossThreadPoolExecutor in order to allow the configuration of max-threads and core-threads independently, while preventing the addition of a thread if an idle thread already exists.
I have attached the state diagrams of the two executors on https://issues.jboss.org/browse/WFLY-5332.

Regards,
Panagiotis Sotiropoulos

From david.lloyd at redhat.com  Thu Sep 24 10:48:18 2015
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 24 Sep 2015 09:48:18 -0500
Subject: [wildfly-dev] Proposal of an additional JBossThreadPoolExecutor
 (WFLY-5332)
In-Reply-To: <1996925021.42617028.1443105710871.JavaMail.zimbra@redhat.com>
References: <855034116.42607534.1443105252450.JavaMail.zimbra@redhat.com>
	<1996925021.42617028.1443105710871.JavaMail.zimbra@redhat.com>
Message-ID: <56040D32.2040606@redhat.com>

Thanks for the effort to do this.  However it is necessary to point out 
that while you have made a very descriptive flowchart of the logic of 
the thread pool, it is unfortunately not actually a state diagram; it 
does not describe the state of the various data structures, and their 
response to external (possibly asynchronous) stimuli, which is what is 
necessary to ascertain the correctness of a concurrent algorithm such as 
the one at the core of a thread pool.

On 09/24/2015 09:41 AM, Panagiotis Sotiropoulos wrote:
> Hello all,
>
> Because of WFLY-5332, I have modified the JBossThreadPoolExecutor in order to allow the configuration of max-threads and core-threads independently, while preventing the addition of a thread if an idle thread already exists.
> I have attached the state diagrams of the two executors on https://issues.jboss.org/browse/WFLY-5332.
>
> Regards,
> Panagiotis Sotiropoulos
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML

From psotirop at redhat.com  Thu Sep 24 11:12:01 2015
From: psotirop at redhat.com (Panagiotis Sotiropoulos)
Date: Thu, 24 Sep 2015 11:12:01 -0400 (EDT)
Subject: [wildfly-dev] Proposal of an additional JBossThreadPoolExecutor
 (WFLY-5332)
In-Reply-To: <56040D32.2040606@redhat.com>
References: <855034116.42607534.1443105252450.JavaMail.zimbra@redhat.com>
	<1996925021.42617028.1443105710871.JavaMail.zimbra@redhat.com>
	<56040D32.2040606@redhat.com>
Message-ID: <642447254.42669527.1443107521863.JavaMail.zimbra@redhat.com>

Hello David,

I will try to create state diagrams that show the states of the data structures in various concurrency cases.

Regards,
Panagiotis

----- Original Message -----
From: "David M. Lloyd" <david.lloyd at redhat.com>
To: wildfly-dev at lists.jboss.org
Sent: Thursday, September 24, 2015 4:48:18 PM
Subject: Re: [wildfly-dev] Proposal of an additional JBossThreadPoolExecutor (WFLY-5332)

Thanks for the effort to do this.  However it is necessary to point out 
that while you have made a very descriptive flowchart of the logic of 
the thread pool, it is unfortunately not actually a state diagram; it 
does not describe the state of the various data structures, and their 
response to external (possibly asynchronous) stimuli, which is what is 
necessary to ascertain the correctness of a concurrent algorithm such as 
the one at the core of a thread pool.

On 09/24/2015 09:41 AM, Panagiotis Sotiropoulos wrote:
> Hello all,
>
> Because of WFLY-5332, I have modified the JBossThreadPoolExecutor in order to allow the configuration of max-threads and core-threads independently, while preventing the addition of a thread if an idle thread already exists.
> I have attached the state diagrams of the two executors on https://issues.jboss.org/browse/WFLY-5332.
>
> Regards,
> Panagiotis Sotiropoulos
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

From alexey.loubyansky at redhat.com  Fri Sep 25 09:08:35 2015
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Fri, 25 Sep 2015 15:08:35 +0200
Subject: [wildfly-dev] issues with IBM JVM on Linux
Message-ID: <56054753.7050706@redhat.com>

I've been trying to narrow down sporadic failures in the wfcore patching 
tests on the IBM JVM on Linux (version info below) for the last few 
days. I wanted to share this because what I see doesn't make sense to 
me. And I am not sure whether other modules have similar issues.

So, in patching tests the (sporadic) problem appears when parsing XML 
attributes. E.g. if there is an element with attributes 'name' and 
'add-on', sometimes the value of name will end up containing the value 
of add-on attribute. Here is the actual code for this (Attribute is an 
enum) from org.jboss.as.patching.metadata.PatchXmlUtils:

String name = null;
boolean isAddOn = false;
final int count = reader.getAttributeCount();
for (int i = 0; i < count; i++) {
     final String value = reader.getAttributeValue(i);
     final Attribute attribute = 
Attribute.forName(reader.getAttributeLocalName(i));
     if(Attribute.NAME == attribute) {
         name = value;
     } else if (Attribute.ADD_ON == attribute) {
         isAddOn = Boolean.valueOf(value);
     } else {
         throw unexpectedAttribute(reader, i);
     }
}

So, sometimes the tests fail because the value of name is 'true', 
apparently. This is just one example. It affects parsing attributes in 
general in this class.

I noticed that if I do anything with variable 'value' in the loop (or 
pass it as an argument to some method and actually do something with it 
in that method), e.g. System.err.println("value=" + value); the problem 
goes away.

Another workaround I've found is to inline the variable, i.e. use 
reader.getAttributeValue(i) directly instead of using a variable.

By the "problem goes away" I mean that I haven't seen these kind of 
failures anymore with the changes I mentioned. To give some statistics, 
with the original code the tests would fail from 2 to 5 times out of 10 
runs.
With the inlined variable value they pass 100%. I've be running them for 
3 days now.

Here is the JVM info.

java version "1.8.0"
Java(TM) SE Runtime Environment (build pxi3280-20150129_02)
IBM J9 VM (build 2.8, JRE 1.8.0 Linux x86-32 20150116_231420 (JIT 
enabled, AOT enabled)
J9VM - R28_Java8_GA_20150116_2030_B231420
JIT  - tr.r14.java_20150109_82886.02
GC   - R28_Java8_GA_20150116_2030_B231420
J9CL - 20150116_231420)
JCL - 20150123_01 based on Oracle jdk8u31-b12


Any ideas or suggestions?


Thanks,
Alexey

From arjan.tijms at gmail.com  Fri Sep 25 09:18:31 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 25 Sep 2015 15:18:31 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
	request#authenticate does nothing now
In-Reply-To: <CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
Message-ID: <CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>

Hi,

I checked again on the just released WildFly 10.0 CR2, but
unfortunately the code is still severely broken now.

There are two main issues, and they're both in this fragment in
JASPIAuthenticationMechanism:

if(isValid == null) {
    isValid = createJASPIAuthenticationManager().isValid(messageInfo,
new Subject(), JASPI_HTTP_SERVLET_LAYER,
attachment.getApplicationIdentifier(), new JBossCallbackHandler());
}

The first problem is the "isValid == null" check. After the first call
to request#authenticate in a given request this will always be
non-null. The result is that a request for programmatic authentication
will effectively be ignored the first time.

The second problem is that this passes in the JBossCallbackHandler,
but this doesn't know how to handle JASPIC callbacks and this will
result in an exception like the following:

javax.security.auth.callback.UnsupportedCallbackException: PBOX00014:
org.jboss.security.auth.callback.JBossCallbackHandler does not handle
a callback of type
javax.security.auth.message.callback.CallerPrincipalCallback
    at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
    at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)

The code should pass in a JASPICallbackHandler here.

Hope this can be fixed. Perhaps it's just a matter of removing the
"isValid == null" check and passing in the right callback handler.

Kind regards,
Arjan Tijms








On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
> p.s. if I just revert JASPIAuthenticationMechanism to the previous
> version, but leaving in the new JASPICInitialHandler, then everything
> seems to work again. This is a bit of hacky workaround perhaps, but in
> some quick testing it does do the trick.
>
> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
>> Hi,
>>
>> It looks like that after WFLY-5298 (this commit specifically
>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6)
>> HttpServletRequest#authenticate does not longer do anything.
>>
>> HttpServletRequest#authenticate calls though to
>> JASPIAuthenticationMechanism#authenticate.
>>
>> There it now obtains the attachment that was set by the new
>> JASPICInitialHandler, which calls the SAM at the beginning of the
>> request. And then uses the stored "isValid" outcome directly, without
>> calling the SAM again.
>>
>> See the code below:
>>
>>   public AuthenticationMechanismOutcome authenticate(final
>> HttpServerExchange exchange, final SecurityContext sc) {
>>         JASPICAttachment attachment =
>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>>
>>         AuthenticationMechanismOutcome outcome;
>>         Account authenticatedAccount = null;
>>
>>         boolean isValid = attachment.isValid();
>>         final ServletRequestContext requestContext =
>> attachment.getRequestContext();
>>         final JASPIServerAuthenticationManager sam = attachment.getSam();
>>         final JASPICallbackHandler cbh = attachment.getCbh();
>>
>>         GenericMessageInfo messageInfo = attachment.getMessageInfo();
>>         if (isValid) {
>>             // The CBH filled in the JBOSS SecurityContext, we need to
>> create an Undertow account based on that
>>             org.jboss.security.SecurityContext jbossSct =
>> SecurityActions.getSecurityContext();
>>             authenticatedAccount =
>> createAccount(attachment.getCachedAccount(), jbossSct);
>>         }
>>
>> This is not correct I think. The code should call the SAM once again
>> and use the outcome from that call.
>>
>> Am I missing something, or was the new call to the SAM simply
>> forgotten at this point?
>>
>> Kind regards,
>> Arjan Tijms

From smarlow at redhat.com  Fri Sep 25 09:18:45 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 25 Sep 2015 09:18:45 -0400
Subject: [wildfly-dev] issues with IBM JVM on Linux
In-Reply-To: <56054753.7050706@redhat.com>
References: <56054753.7050706@redhat.com>
Message-ID: <560549B5.6080308@redhat.com>

Are you using the latest JVM?  From [1], it looks like the last update 
was on July 17th 2015.

Does it make a difference whether the classes were generated by the IBM 
versus Oracle versus OpenJDK compiler?

Scott

[1] http://www.ibm.com/developerworks/java/jdk/linux/download.html

On 09/25/2015 09:08 AM, Alexey Loubyansky wrote:
> I've been trying to narrow down sporadic failures in the wfcore patching
> tests on the IBM JVM on Linux (version info below) for the last few
> days. I wanted to share this because what I see doesn't make sense to
> me. And I am not sure whether other modules have similar issues.
>
> So, in patching tests the (sporadic) problem appears when parsing XML
> attributes. E.g. if there is an element with attributes 'name' and
> 'add-on', sometimes the value of name will end up containing the value
> of add-on attribute. Here is the actual code for this (Attribute is an
> enum) from org.jboss.as.patching.metadata.PatchXmlUtils:
>
> String name = null;
> boolean isAddOn = false;
> final int count = reader.getAttributeCount();
> for (int i = 0; i < count; i++) {
>       final String value = reader.getAttributeValue(i);
>       final Attribute attribute =
> Attribute.forName(reader.getAttributeLocalName(i));
>       if(Attribute.NAME == attribute) {
>           name = value;
>       } else if (Attribute.ADD_ON == attribute) {
>           isAddOn = Boolean.valueOf(value);
>       } else {
>           throw unexpectedAttribute(reader, i);
>       }
> }
>
> So, sometimes the tests fail because the value of name is 'true',
> apparently. This is just one example. It affects parsing attributes in
> general in this class.
>
> I noticed that if I do anything with variable 'value' in the loop (or
> pass it as an argument to some method and actually do something with it
> in that method), e.g. System.err.println("value=" + value); the problem
> goes away.
>
> Another workaround I've found is to inline the variable, i.e. use
> reader.getAttributeValue(i) directly instead of using a variable.
>
> By the "problem goes away" I mean that I haven't seen these kind of
> failures anymore with the changes I mentioned. To give some statistics,
> with the original code the tests would fail from 2 to 5 times out of 10
> runs.
> With the inlined variable value they pass 100%. I've be running them for
> 3 days now.
>
> Here is the JVM info.
>
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxi3280-20150129_02)
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux x86-32 20150116_231420 (JIT
> enabled, AOT enabled)
> J9VM - R28_Java8_GA_20150116_2030_B231420
> JIT  - tr.r14.java_20150109_82886.02
> GC   - R28_Java8_GA_20150116_2030_B231420
> J9CL - 20150116_231420)
> JCL - 20150123_01 based on Oracle jdk8u31-b12
>
>
> Any ideas or suggestions?
>
>
> Thanks,
> Alexey
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From jason.greene at redhat.com  Fri Sep 25 09:41:57 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Fri, 25 Sep 2015 09:41:57 -0400 (EDT)
Subject: [wildfly-dev] issues with IBM JVM on Linux
In-Reply-To: <56054753.7050706@redhat.com>
References: <56054753.7050706@redhat.com>
Message-ID: <8B2425F0-0BA3-4754-AEF9-1EA1452FB6AB@redhat.com>

Sounds like bad opto. Can you try with -Xint?

> On Sep 25, 2015, at 8:09 AM, Alexey Loubyansky <alexey.loubyansky at redhat.com> wrote:
> 
> I've been trying to narrow down sporadic failures in the wfcore patching 
> tests on the IBM JVM on Linux (version info below) for the last few 
> days. I wanted to share this because what I see doesn't make sense to 
> me. And I am not sure whether other modules have similar issues.
> 
> So, in patching tests the (sporadic) problem appears when parsing XML 
> attributes. E.g. if there is an element with attributes 'name' and 
> 'add-on', sometimes the value of name will end up containing the value 
> of add-on attribute. Here is the actual code for this (Attribute is an 
> enum) from org.jboss.as.patching.metadata.PatchXmlUtils:
> 
> String name = null;
> boolean isAddOn = false;
> final int count = reader.getAttributeCount();
> for (int i = 0; i < count; i++) {
>     final String value = reader.getAttributeValue(i);
>     final Attribute attribute = 
> Attribute.forName(reader.getAttributeLocalName(i));
>     if(Attribute.NAME == attribute) {
>         name = value;
>     } else if (Attribute.ADD_ON == attribute) {
>         isAddOn = Boolean.valueOf(value);
>     } else {
>         throw unexpectedAttribute(reader, i);
>     }
> }
> 
> So, sometimes the tests fail because the value of name is 'true', 
> apparently. This is just one example. It affects parsing attributes in 
> general in this class.
> 
> I noticed that if I do anything with variable 'value' in the loop (or 
> pass it as an argument to some method and actually do something with it 
> in that method), e.g. System.err.println("value=" + value); the problem 
> goes away.
> 
> Another workaround I've found is to inline the variable, i.e. use 
> reader.getAttributeValue(i) directly instead of using a variable.
> 
> By the "problem goes away" I mean that I haven't seen these kind of 
> failures anymore with the changes I mentioned. To give some statistics, 
> with the original code the tests would fail from 2 to 5 times out of 10 
> runs.
> With the inlined variable value they pass 100%. I've be running them for 
> 3 days now.
> 
> Here is the JVM info.
> 
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxi3280-20150129_02)
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux x86-32 20150116_231420 (JIT 
> enabled, AOT enabled)
> J9VM - R28_Java8_GA_20150116_2030_B231420
> JIT  - tr.r14.java_20150109_82886.02
> GC   - R28_Java8_GA_20150116_2030_B231420
> J9CL - 20150116_231420)
> JCL - 20150123_01 based on Oracle jdk8u31-b12
> 
> 
> Any ideas or suggestions?
> 
> 
> Thanks,
> Alexey
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From psotirop at redhat.com  Fri Sep 25 10:20:19 2015
From: psotirop at redhat.com (Panagiotis Sotiropoulos)
Date: Fri, 25 Sep 2015 10:20:19 -0400 (EDT)
Subject: [wildfly-dev] Proposal of an additional JBossThreadPoolExecutor
 (WFLY-5332)
In-Reply-To: <642447254.42669527.1443107521863.JavaMail.zimbra@redhat.com>
References: <855034116.42607534.1443105252450.JavaMail.zimbra@redhat.com>
	<1996925021.42617028.1443105710871.JavaMail.zimbra@redhat.com>
	<56040D32.2040606@redhat.com>
	<642447254.42669527.1443107521863.JavaMail.zimbra@redhat.com>
Message-ID: <1089617426.43601292.1443190819089.JavaMail.zimbra@redhat.com>

Hello David,

I have added a diagram that describes the states of the basic variables of the Modified JBoss Thread Pool Executor.
As far as concurrency safety is concerned, the key point is this:
Line #1179 of https://github.com/jbossas/jboss-threads/pull/17/files ...
If there are no idle threads then new threads will be created, which is ok.
If there are few idle threads and we receive a lot of concurrent requests then all these requests will consider that there is at least one idle thread, but again no problem as the will be en queued to the work queue and go on from there.

Regards,
Panagiotis

----- Original Message -----
From: "Panagiotis Sotiropoulos" <psotirop at redhat.com>
To: "David M. Lloyd" <david.lloyd at redhat.com>
Cc: wildfly-dev at lists.jboss.org
Sent: Thursday, September 24, 2015 5:12:01 PM
Subject: Re: [wildfly-dev] Proposal of an additional JBossThreadPoolExecutor (WFLY-5332)

Hello David,

I will try to create state diagrams that show the states of the data structures in various concurrency cases.

Regards,
Panagiotis

----- Original Message -----
From: "David M. Lloyd" <david.lloyd at redhat.com>
To: wildfly-dev at lists.jboss.org
Sent: Thursday, September 24, 2015 4:48:18 PM
Subject: Re: [wildfly-dev] Proposal of an additional JBossThreadPoolExecutor (WFLY-5332)

Thanks for the effort to do this.  However it is necessary to point out 
that while you have made a very descriptive flowchart of the logic of 
the thread pool, it is unfortunately not actually a state diagram; it 
does not describe the state of the various data structures, and their 
response to external (possibly asynchronous) stimuli, which is what is 
necessary to ascertain the correctness of a concurrent algorithm such as 
the one at the core of a thread pool.

On 09/24/2015 09:41 AM, Panagiotis Sotiropoulos wrote:
> Hello all,
>
> Because of WFLY-5332, I have modified the JBossThreadPoolExecutor in order to allow the configuration of max-threads and core-threads independently, while preventing the addition of a thread if an idle thread already exists.
> I have attached the state diagrams of the two executors on https://issues.jboss.org/browse/WFLY-5332.
>
> Regards,
> Panagiotis Sotiropoulos
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev

From arjan.tijms at gmail.com  Fri Sep 25 11:14:47 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Fri, 25 Sep 2015 17:14:47 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
	request#authenticate does nothing now
In-Reply-To: <CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
Message-ID: <CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>

Hi,

I discovered some more issues originating from 5298:

pre-emptive authentication on a public page doesn't work anymore
either. It still worked fine in WildFly 9.0.1.

This can be easily seen when running the JASPIC tests from
https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic

For the basic authentication tests, the following now fail:

Failed tests:
  testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
  testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)

These tests don't rely on request#authenticate, but depend on
automatic calling of a SAM at the beginning of a request. After manual
inspection it's clear that the SAM is called, but its outcome is not
being applied.

Kind regards,
Arjan





On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
> Hi,
>
> I checked again on the just released WildFly 10.0 CR2, but
> unfortunately the code is still severely broken now.
>
> There are two main issues, and they're both in this fragment in
> JASPIAuthenticationMechanism:
>
> if(isValid == null) {
>     isValid = createJASPIAuthenticationManager().isValid(messageInfo,
> new Subject(), JASPI_HTTP_SERVLET_LAYER,
> attachment.getApplicationIdentifier(), new JBossCallbackHandler());
> }
>
> The first problem is the "isValid == null" check. After the first call
> to request#authenticate in a given request this will always be
> non-null. The result is that a request for programmatic authentication
> will effectively be ignored the first time.
>
> The second problem is that this passes in the JBossCallbackHandler,
> but this doesn't know how to handle JASPIC callbacks and this will
> result in an exception like the following:
>
> javax.security.auth.callback.UnsupportedCallbackException: PBOX00014:
> org.jboss.security.auth.callback.JBossCallbackHandler does not handle
> a callback of type
> javax.security.auth.message.callback.CallerPrincipalCallback
>     at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>     at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>
> The code should pass in a JASPICallbackHandler here.
>
> Hope this can be fixed. Perhaps it's just a matter of removing the
> "isValid == null" check and passing in the right callback handler.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
> On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
>> p.s. if I just revert JASPIAuthenticationMechanism to the previous
>> version, but leaving in the new JASPICInitialHandler, then everything
>> seems to work again. This is a bit of hacky workaround perhaps, but in
>> some quick testing it does do the trick.
>>
>> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
>>> Hi,
>>>
>>> It looks like that after WFLY-5298 (this commit specifically
>>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6)
>>> HttpServletRequest#authenticate does not longer do anything.
>>>
>>> HttpServletRequest#authenticate calls though to
>>> JASPIAuthenticationMechanism#authenticate.
>>>
>>> There it now obtains the attachment that was set by the new
>>> JASPICInitialHandler, which calls the SAM at the beginning of the
>>> request. And then uses the stored "isValid" outcome directly, without
>>> calling the SAM again.
>>>
>>> See the code below:
>>>
>>>   public AuthenticationMechanismOutcome authenticate(final
>>> HttpServerExchange exchange, final SecurityContext sc) {
>>>         JASPICAttachment attachment =
>>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>>>
>>>         AuthenticationMechanismOutcome outcome;
>>>         Account authenticatedAccount = null;
>>>
>>>         boolean isValid = attachment.isValid();
>>>         final ServletRequestContext requestContext =
>>> attachment.getRequestContext();
>>>         final JASPIServerAuthenticationManager sam = attachment.getSam();
>>>         final JASPICallbackHandler cbh = attachment.getCbh();
>>>
>>>         GenericMessageInfo messageInfo = attachment.getMessageInfo();
>>>         if (isValid) {
>>>             // The CBH filled in the JBOSS SecurityContext, we need to
>>> create an Undertow account based on that
>>>             org.jboss.security.SecurityContext jbossSct =
>>> SecurityActions.getSecurityContext();
>>>             authenticatedAccount =
>>> createAccount(attachment.getCachedAccount(), jbossSct);
>>>         }
>>>
>>> This is not correct I think. The code should call the SAM once again
>>> and use the outcome from that call.
>>>
>>> Am I missing something, or was the new call to the SAM simply
>>> forgotten at this point?
>>>
>>> Kind regards,
>>> Arjan Tijms

From alexey.loubyansky at redhat.com  Fri Sep 25 12:39:52 2015
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Fri, 25 Sep 2015 18:39:52 +0200
Subject: [wildfly-dev] issues with IBM JVM on Linux
In-Reply-To: <560549B5.6080308@redhat.com>
References: <56054753.7050706@redhat.com> <560549B5.6080308@redhat.com>
Message-ID: <560578D8.1090200@redhat.com>

On 09/25/2015 03:18 PM, Scott Marlow wrote:
> Are you using the latest JVM?  From [1], it looks like the last update
> was on July 17th 2015.

No, I've been using the one we have installed in brontes to be able to 
reproduce.

But I've tried the latest and it still fails occasionally although less 
often: once or twice in 10 runs. So it appears to be better than the one 
we've been using. Tomaz is going to upgrade it.

> Does it make a difference whether the classes were generated by the IBM
> versus Oracle versus OpenJDK compiler?

Haven't tried that yet.

Thanks,
Alexey

> Scott
>
> [1] http://www.ibm.com/developerworks/java/jdk/linux/download.html
>
> On 09/25/2015 09:08 AM, Alexey Loubyansky wrote:
>> I've been trying to narrow down sporadic failures in the wfcore patching
>> tests on the IBM JVM on Linux (version info below) for the last few
>> days. I wanted to share this because what I see doesn't make sense to
>> me. And I am not sure whether other modules have similar issues.
>>
>> So, in patching tests the (sporadic) problem appears when parsing XML
>> attributes. E.g. if there is an element with attributes 'name' and
>> 'add-on', sometimes the value of name will end up containing the value
>> of add-on attribute. Here is the actual code for this (Attribute is an
>> enum) from org.jboss.as.patching.metadata.PatchXmlUtils:
>>
>> String name = null;
>> boolean isAddOn = false;
>> final int count = reader.getAttributeCount();
>> for (int i = 0; i < count; i++) {
>>        final String value = reader.getAttributeValue(i);
>>        final Attribute attribute =
>> Attribute.forName(reader.getAttributeLocalName(i));
>>        if(Attribute.NAME == attribute) {
>>            name = value;
>>        } else if (Attribute.ADD_ON == attribute) {
>>            isAddOn = Boolean.valueOf(value);
>>        } else {
>>            throw unexpectedAttribute(reader, i);
>>        }
>> }
>>
>> So, sometimes the tests fail because the value of name is 'true',
>> apparently. This is just one example. It affects parsing attributes in
>> general in this class.
>>
>> I noticed that if I do anything with variable 'value' in the loop (or
>> pass it as an argument to some method and actually do something with it
>> in that method), e.g. System.err.println("value=" + value); the problem
>> goes away.
>>
>> Another workaround I've found is to inline the variable, i.e. use
>> reader.getAttributeValue(i) directly instead of using a variable.
>>
>> By the "problem goes away" I mean that I haven't seen these kind of
>> failures anymore with the changes I mentioned. To give some statistics,
>> with the original code the tests would fail from 2 to 5 times out of 10
>> runs.
>> With the inlined variable value they pass 100%. I've be running them for
>> 3 days now.
>>
>> Here is the JVM info.
>>
>> java version "1.8.0"
>> Java(TM) SE Runtime Environment (build pxi3280-20150129_02)
>> IBM J9 VM (build 2.8, JRE 1.8.0 Linux x86-32 20150116_231420 (JIT
>> enabled, AOT enabled)
>> J9VM - R28_Java8_GA_20150116_2030_B231420
>> JIT  - tr.r14.java_20150109_82886.02
>> GC   - R28_Java8_GA_20150116_2030_B231420
>> J9CL - 20150116_231420)
>> JCL - 20150123_01 based on Oracle jdk8u31-b12
>>
>>
>> Any ideas or suggestions?
>>
>>
>> Thanks,
>> Alexey
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From rodakr at gmx.ch  Fri Sep 25 14:14:35 2015
From: rodakr at gmx.ch (Radoslaw Rodak)
Date: Fri, 25 Sep 2015 20:14:35 +0200
Subject: [wildfly-dev] issues with IBM JVM on Linux
In-Reply-To: <560578D8.1090200@redhat.com>
References: <56054753.7050706@redhat.com> <560549B5.6080308@redhat.com>
	<560578D8.1090200@redhat.com>
Message-ID: <914C3086-2A71-457B-8C55-77D1CFF4C778@gmx.ch>

Hi

Few months ago I had pretty similar issue on IBM JDK , but version 1.7.0 .

Doing 10 time same xslt transformation randomly it was failing.

Problem was JIT Compiler Bug in IBM JDK?. issue was fix in newer Version of IBM JDK.
Best ist to get newest IBM JDK Version.

Work Arround for me on IBM JDK was to use  TransformerFactory , which is used as default on Oracle JDK on Linux and Windows, which is not the case on IBM JDK...:

-Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl

To see if the error is really because of IBM JIT ( begin of this year IBM JDK had a lot of JIT bugfixes? ) you can also just turn off JIT ( -Xnojit ) and see if the problem still happened ( side effect test will run very slow )

P.S:

Interesting side Effect was, transformation was 50% faster with Xalan Implementation compared to default IBM TransformerFactory ?

Cheers
Radek

Am 25.09.2015 um 18:39 schrieb Alexey Loubyansky <alexey.loubyansky at redhat.com>:

> On 09/25/2015 03:18 PM, Scott Marlow wrote:
>> Are you using the latest JVM?  From [1], it looks like the last update
>> was on July 17th 2015.
> 
> No, I've been using the one we have installed in brontes to be able to 
> reproduce.
> 
> But I've tried the latest and it still fails occasionally although less 
> often: once or twice in 10 runs. So it appears to be better than the one 
> we've been using. Tomaz is going to upgrade it.
> 
>> Does it make a difference whether the classes were generated by the IBM
>> versus Oracle versus OpenJDK compiler?
> 
> Haven't tried that yet.
> 
> Thanks,
> Alexey
> 
>> Scott
>> 
>> [1] http://www.ibm.com/developerworks/java/jdk/linux/download.html
>> 
>> On 09/25/2015 09:08 AM, Alexey Loubyansky wrote:
>>> I've been trying to narrow down sporadic failures in the wfcore patching
>>> tests on the IBM JVM on Linux (version info below) for the last few
>>> days. I wanted to share this because what I see doesn't make sense to
>>> me. And I am not sure whether other modules have similar issues.
>>> 
>>> So, in patching tests the (sporadic) problem appears when parsing XML
>>> attributes. E.g. if there is an element with attributes 'name' and
>>> 'add-on', sometimes the value of name will end up containing the value
>>> of add-on attribute. Here is the actual code for this (Attribute is an
>>> enum) from org.jboss.as.patching.metadata.PatchXmlUtils:
>>> 
>>> String name = null;
>>> boolean isAddOn = false;
>>> final int count = reader.getAttributeCount();
>>> for (int i = 0; i < count; i++) {
>>>       final String value = reader.getAttributeValue(i);
>>>       final Attribute attribute =
>>> Attribute.forName(reader.getAttributeLocalName(i));
>>>       if(Attribute.NAME == attribute) {
>>>           name = value;
>>>       } else if (Attribute.ADD_ON == attribute) {
>>>           isAddOn = Boolean.valueOf(value);
>>>       } else {
>>>           throw unexpectedAttribute(reader, i);
>>>       }
>>> }
>>> 
>>> So, sometimes the tests fail because the value of name is 'true',
>>> apparently. This is just one example. It affects parsing attributes in
>>> general in this class.
>>> 
>>> I noticed that if I do anything with variable 'value' in the loop (or
>>> pass it as an argument to some method and actually do something with it
>>> in that method), e.g. System.err.println("value=" + value); the problem
>>> goes away.
>>> 
>>> Another workaround I've found is to inline the variable, i.e. use
>>> reader.getAttributeValue(i) directly instead of using a variable.
>>> 
>>> By the "problem goes away" I mean that I haven't seen these kind of
>>> failures anymore with the changes I mentioned. To give some statistics,
>>> with the original code the tests would fail from 2 to 5 times out of 10
>>> runs.
>>> With the inlined variable value they pass 100%. I've be running them for
>>> 3 days now.
>>> 
>>> Here is the JVM info.
>>> 
>>> java version "1.8.0"
>>> Java(TM) SE Runtime Environment (build pxi3280-20150129_02)
>>> IBM J9 VM (build 2.8, JRE 1.8.0 Linux x86-32 20150116_231420 (JIT
>>> enabled, AOT enabled)
>>> J9VM - R28_Java8_GA_20150116_2030_B231420
>>> JIT  - tr.r14.java_20150109_82886.02
>>> GC   - R28_Java8_GA_20150116_2030_B231420
>>> J9CL - 20150116_231420)
>>> JCL - 20150123_01 based on Oracle jdk8u31-b12
>>> 
>>> 
>>> Any ideas or suggestions?
>>> 
>>> 
>>> Thanks,
>>> Alexey
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From tomaz.cerar at gmail.com  Sat Sep 26 08:45:23 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Sat, 26 Sep 2015 14:45:23 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
Message-ID: <CAMquZP5eHvk1WHwPDfH-8b_OrYCDTyMy1mN248-5-Y0i_AeHFg@mail.gmail.com>

I think if would make sense to port / include at least some of this tests
to
wildfly testsuite, so we would make sure we don't break anything
unintentionally.

This way it would be tested for every pull request and in every job we run
on multiple platforms.

--
tomaz

On Fri, Sep 25, 2015 at 5:14 PM, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> I discovered some more issues originating from 5298:
>
> pre-emptive authentication on a public page doesn't work anymore
> either. It still worked fine in WildFly 9.0.1.
>
> This can be easily seen when running the JASPIC tests from
> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>
> For the basic authentication tests, the following now fail:
>
> Failed tests:
>
> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>
> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>
> These tests don't rely on request#authenticate, but depend on
> automatic calling of a SAM at the beginning of a request. After manual
> inspection it's clear that the SAM is called, but its outcome is not
> being applied.
>
> Kind regards,
> Arjan
>
>
>
>
>
> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
> > Hi,
> >
> > I checked again on the just released WildFly 10.0 CR2, but
> > unfortunately the code is still severely broken now.
> >
> > There are two main issues, and they're both in this fragment in
> > JASPIAuthenticationMechanism:
> >
> > if(isValid == null) {
> >     isValid = createJASPIAuthenticationManager().isValid(messageInfo,
> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
> > attachment.getApplicationIdentifier(), new JBossCallbackHandler());
> > }
> >
> > The first problem is the "isValid == null" check. After the first call
> > to request#authenticate in a given request this will always be
> > non-null. The result is that a request for programmatic authentication
> > will effectively be ignored the first time.
> >
> > The second problem is that this passes in the JBossCallbackHandler,
> > but this doesn't know how to handle JASPIC callbacks and this will
> > result in an exception like the following:
> >
> > javax.security.auth.callback.UnsupportedCallbackException: PBOX00014:
> > org.jboss.security.auth.callback.JBossCallbackHandler does not handle
> > a callback of type
> > javax.security.auth.message.callback.CallerPrincipalCallback
> >     at
> org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
> >     at
> org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
> >
> > The code should pass in a JASPICallbackHandler here.
> >
> > Hope this can be fixed. Perhaps it's just a matter of removing the
> > "isValid == null" check and passing in the right callback handler.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
> >> p.s. if I just revert JASPIAuthenticationMechanism to the previous
> >> version, but leaving in the new JASPICInitialHandler, then everything
> >> seems to work again. This is a bit of hacky workaround perhaps, but in
> >> some quick testing it does do the trick.
> >>
> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
> >>> Hi,
> >>>
> >>> It looks like that after WFLY-5298 (this commit specifically
> >>>
> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6
> )
> >>> HttpServletRequest#authenticate does not longer do anything.
> >>>
> >>> HttpServletRequest#authenticate calls though to
> >>> JASPIAuthenticationMechanism#authenticate.
> >>>
> >>> There it now obtains the attachment that was set by the new
> >>> JASPICInitialHandler, which calls the SAM at the beginning of the
> >>> request. And then uses the stored "isValid" outcome directly, without
> >>> calling the SAM again.
> >>>
> >>> See the code below:
> >>>
> >>>   public AuthenticationMechanismOutcome authenticate(final
> >>> HttpServerExchange exchange, final SecurityContext sc) {
> >>>         JASPICAttachment attachment =
> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
> >>>
> >>>         AuthenticationMechanismOutcome outcome;
> >>>         Account authenticatedAccount = null;
> >>>
> >>>         boolean isValid = attachment.isValid();
> >>>         final ServletRequestContext requestContext =
> >>> attachment.getRequestContext();
> >>>         final JASPIServerAuthenticationManager sam =
> attachment.getSam();
> >>>         final JASPICallbackHandler cbh = attachment.getCbh();
> >>>
> >>>         GenericMessageInfo messageInfo = attachment.getMessageInfo();
> >>>         if (isValid) {
> >>>             // The CBH filled in the JBOSS SecurityContext, we need to
> >>> create an Undertow account based on that
> >>>             org.jboss.security.SecurityContext jbossSct =
> >>> SecurityActions.getSecurityContext();
> >>>             authenticatedAccount =
> >>> createAccount(attachment.getCachedAccount(), jbossSct);
> >>>         }
> >>>
> >>> This is not correct I think. The code should call the SAM once again
> >>> and use the outcome from that call.
> >>>
> >>> Am I missing something, or was the new call to the SAM simply
> >>> forgotten at this point?
> >>>
> >>> Kind regards,
> >>> Arjan Tijms
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150926/bc2e8233/attachment-0001.html 

From arjan.tijms at gmail.com  Sat Sep 26 10:51:52 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Sat, 26 Sep 2015 16:51:52 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAMquZP5eHvk1WHwPDfH-8b_OrYCDTyMy1mN248-5-Y0i_AeHFg@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAMquZP5eHvk1WHwPDfH-8b_OrYCDTyMy1mN248-5-Y0i_AeHFg@mail.gmail.com>
Message-ID: <CAE=-AhAfJwfvViMZ7ias7f4QNvTk3WGA_15PwE=vuTwCwvoDTA@mail.gmail.com>

Hi,

On Sat, Sep 26, 2015 at 2:45 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
> I think if would make sense to port / include at least some of this tests to
> wildfly testsuite, so we would make sure we don't break anything
> unintentionally.

I'm absolutely in favour of this.

I'm the original and sole author of all code itself (only changes by
others have been formatting, and some global renaming for pom artefact
names), but the project itself puts all files under the MIT license.
IANAL, so I'm not sure if the tests would have to be ported then using
that MIT license and whether me being the only author has any
influence on that.

Cloning that project and then only building/running the JASPIC module
may be another option.

Kind regards,
Arjan

>
> This way it would be tested for every pull request and in every job we run
> on multiple platforms.
>
> --
> tomaz
>
> On Fri, Sep 25, 2015 at 5:14 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
>>
>> Hi,
>>
>> I discovered some more issues originating from 5298:
>>
>> pre-emptive authentication on a public page doesn't work anymore
>> either. It still worked fine in WildFly 9.0.1.
>>
>> This can be easily seen when running the JASPIC tests from
>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>
>> For the basic authentication tests, the following now fail:
>>
>> Failed tests:
>>
>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>
>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>
>> These tests don't rely on request#authenticate, but depend on
>> automatic calling of a SAM at the beginning of a request. After manual
>> inspection it's clear that the SAM is called, but its outcome is not
>> being applied.
>>
>> Kind regards,
>> Arjan
>>
>>
>>
>>
>>
>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > I checked again on the just released WildFly 10.0 CR2, but
>> > unfortunately the code is still severely broken now.
>> >
>> > There are two main issues, and they're both in this fragment in
>> > JASPIAuthenticationMechanism:
>> >
>> > if(isValid == null) {
>> >     isValid = createJASPIAuthenticationManager().isValid(messageInfo,
>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>> > attachment.getApplicationIdentifier(), new JBossCallbackHandler());
>> > }
>> >
>> > The first problem is the "isValid == null" check. After the first call
>> > to request#authenticate in a given request this will always be
>> > non-null. The result is that a request for programmatic authentication
>> > will effectively be ignored the first time.
>> >
>> > The second problem is that this passes in the JBossCallbackHandler,
>> > but this doesn't know how to handle JASPIC callbacks and this will
>> > result in an exception like the following:
>> >
>> > javax.security.auth.callback.UnsupportedCallbackException: PBOX00014:
>> > org.jboss.security.auth.callback.JBossCallbackHandler does not handle
>> > a callback of type
>> > javax.security.auth.message.callback.CallerPrincipalCallback
>> >     at
>> > org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>> >     at
>> > org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>> >
>> > The code should pass in a JASPICallbackHandler here.
>> >
>> > Hope this can be fixed. Perhaps it's just a matter of removing the
>> > "isValid == null" check and passing in the right callback handler.
>> >
>> > Kind regards,
>> > Arjan Tijms
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <arjan.tijms at gmail.com>
>> > wrote:
>> >> p.s. if I just revert JASPIAuthenticationMechanism to the previous
>> >> version, but leaving in the new JASPICInitialHandler, then everything
>> >> seems to work again. This is a bit of hacky workaround perhaps, but in
>> >> some quick testing it does do the trick.
>> >>
>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <arjan.tijms at gmail.com>
>> >> wrote:
>> >>> Hi,
>> >>>
>> >>> It looks like that after WFLY-5298 (this commit specifically
>> >>>
>> >>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6)
>> >>> HttpServletRequest#authenticate does not longer do anything.
>> >>>
>> >>> HttpServletRequest#authenticate calls though to
>> >>> JASPIAuthenticationMechanism#authenticate.
>> >>>
>> >>> There it now obtains the attachment that was set by the new
>> >>> JASPICInitialHandler, which calls the SAM at the beginning of the
>> >>> request. And then uses the stored "isValid" outcome directly, without
>> >>> calling the SAM again.
>> >>>
>> >>> See the code below:
>> >>>
>> >>>   public AuthenticationMechanismOutcome authenticate(final
>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>> >>>         JASPICAttachment attachment =
>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>> >>>
>> >>>         AuthenticationMechanismOutcome outcome;
>> >>>         Account authenticatedAccount = null;
>> >>>
>> >>>         boolean isValid = attachment.isValid();
>> >>>         final ServletRequestContext requestContext =
>> >>> attachment.getRequestContext();
>> >>>         final JASPIServerAuthenticationManager sam =
>> >>> attachment.getSam();
>> >>>         final JASPICallbackHandler cbh = attachment.getCbh();
>> >>>
>> >>>         GenericMessageInfo messageInfo = attachment.getMessageInfo();
>> >>>         if (isValid) {
>> >>>             // The CBH filled in the JBOSS SecurityContext, we need to
>> >>> create an Undertow account based on that
>> >>>             org.jboss.security.SecurityContext jbossSct =
>> >>> SecurityActions.getSecurityContext();
>> >>>             authenticatedAccount =
>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>> >>>         }
>> >>>
>> >>> This is not correct I think. The code should call the SAM once again
>> >>> and use the outcome from that call.
>> >>>
>> >>> Am I missing something, or was the new call to the SAM simply
>> >>> forgotten at this point?
>> >>>
>> >>> Kind regards,
>> >>> Arjan Tijms
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>


From spaulger at codezen.co.uk  Sat Sep 26 17:12:22 2015
From: spaulger at codezen.co.uk (Simon Paulger)
Date: Sat, 26 Sep 2015 22:12:22 +0100
Subject: [wildfly-dev] Wildfly Redis infinispan cache store
In-Reply-To: <5C213E3E-A418-454B-8C14-CBA883C05CAF@codezen.co.uk>
References: <CAHadGstN++dRG6A5UYMZ2BaGNwfucTXgq9un8YykDFs0Yr08CQ@mail.gmail.com>
	<E9381A0F-D9B4-47BE-9D1D-45076BE7DF15@redhat.com>
	<5C213E3E-A418-454B-8C14-CBA883C05CAF@codezen.co.uk>
Message-ID: <CAHadGsupE=bKHJB2MM003wjFW6itLkPJFDOpofsoUHA_WsO3vg@mail.gmail.com>

Hi,

I just want to re-iterate this to try and get it ready for the final
Wildfly 10 release. In order to make Redis integration, what changes should
I be making? In particular;


   1. xml reader/writer - should I be adding redis-store as a concrete xml
   tag?
   2. persistence pom updates to add the redis jar dependency
   3. xsd documentation updates
   4. module configurations
   5. jboss-cli - do I need to add a redis-store type to a cache container?
   6. web management console - again redis-store type to a cache container?


1 - 3 are done, 4 is in progress, however I am unclear on how to make 5 and
6 (can't find the code locations), and I also want steer on whether a
concrete store type is needed or if the custom store should be the way to
go, in which case I think only pom updates and module config is required.

Kind regards,
Simon

On 15 September 2015 at 14:38, Simon Paulger <spaulger at codezen.co.uk> wrote:

> Hi Jason,
>
> I have developed a redis cache store which has now been completed and
> released under the infinispan org as part of version 8, available through
> central.
>
> I had begun to look at what changes would be required under wildfly. I
> have made changes to the xml reader and writer for config for a concrete
> redis-store type but haven't worked out how to update the web ui and cli.
>
> This got me thinking as to whether a concrete config tag is required at
> all since there is always the custom store.
>
> Therefore, I thought I'd check. What changes should I be developing to
> make my redis integration in to wildfly 10?
>
> Thanks
> Simon
>
> Sent from my iPhone
>
> On 28 Jul 2015, at 21:22, Jason Greene <jason.greene at redhat.com> wrote:
>
>
> On Jul 28, 2015, at 3:04 PM, Simon Paulger <spaulger at codezen.co.uk> wrote:
>
> Hi,
>
> My company uses JBoss AS 7 (before Wildfly I know). We also use Redis
> cache store for PHP stacks and I'd like to be able to do the same for
> Wildfly (I'm considering upgrade paths).
>
> I see there is an old JIRA enhancement issue raised here:
> https://issues.jboss.org/browse/ISPN-3465
>
> I was wondering what the appetite for creating a Redis cache store is. If
> this were something I were to develop in both inifinispan and wildfly,
> would it be well received by the JBoss community?
>
>
> Hi Simon,
>
> Thanks for the interest, and it sounds great to me!
>
> I would recommend starting by posting to infinispan-dev your interest in
> the feature (if you haven?t already), and they can help you get started. I
> would imagine the infinispan memcached code is a good starting point, and
> may in fact be adaptable to the Redis protocol, perhaps by forking it.
>
> One thats done there is some integration bits on the WildFly side, but I
> wouldn?t worry about that until its shipped in an infinispan release.
>
> Thanks,
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150926/c44e109b/attachment.html 

From stuart.w.douglas at gmail.com  Sun Sep 27 19:49:22 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Sun, 27 Sep 2015 23:49:22 +0000
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
Message-ID: <CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>

This was deliberately disabled to match the behavior of EAP6. It can be
controlled by the proactive-authentication attribute on the servlet
container. These JAPIC changes have been driven by this change, in order to
get the TCK to pass without proactive auth. I will look into it today.

If you can contribute your tests it would be greatly appreciated, we do not
have much coverage (and apparently neither does the TCK, as it does not
pick up these issues). As I understand it if you are the sole author you
retain copyright and can re-license them under whatever license you like.

Stuart

On Sat, 26 Sep 2015 at 01:15 arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> I discovered some more issues originating from 5298:
>
> pre-emptive authentication on a public page doesn't work anymore
> either. It still worked fine in WildFly 9.0.1.
>
> This can be easily seen when running the JASPIC tests from
> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>
> For the basic authentication tests, the following now fail:
>
> Failed tests:
>
> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>
> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>
> These tests don't rely on request#authenticate, but depend on
> automatic calling of a SAM at the beginning of a request. After manual
> inspection it's clear that the SAM is called, but its outcome is not
> being applied.
>
> Kind regards,
> Arjan
>
>
>
>
>
> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
> > Hi,
> >
> > I checked again on the just released WildFly 10.0 CR2, but
> > unfortunately the code is still severely broken now.
> >
> > There are two main issues, and they're both in this fragment in
> > JASPIAuthenticationMechanism:
> >
> > if(isValid == null) {
> >     isValid = createJASPIAuthenticationManager().isValid(messageInfo,
> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
> > attachment.getApplicationIdentifier(), new JBossCallbackHandler());
> > }
> >
> > The first problem is the "isValid == null" check. After the first call
> > to request#authenticate in a given request this will always be
> > non-null. The result is that a request for programmatic authentication
> > will effectively be ignored the first time.
> >
> > The second problem is that this passes in the JBossCallbackHandler,
> > but this doesn't know how to handle JASPIC callbacks and this will
> > result in an exception like the following:
> >
> > javax.security.auth.callback.UnsupportedCallbackException: PBOX00014:
> > org.jboss.security.auth.callback.JBossCallbackHandler does not handle
> > a callback of type
> > javax.security.auth.message.callback.CallerPrincipalCallback
> >     at
> org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
> >     at
> org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
> >
> > The code should pass in a JASPICallbackHandler here.
> >
> > Hope this can be fixed. Perhaps it's just a matter of removing the
> > "isValid == null" check and passing in the right callback handler.
> >
> > Kind regards,
> > Arjan Tijms
> >
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
> >> p.s. if I just revert JASPIAuthenticationMechanism to the previous
> >> version, but leaving in the new JASPICInitialHandler, then everything
> >> seems to work again. This is a bit of hacky workaround perhaps, but in
> >> some quick testing it does do the trick.
> >>
> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <arjan.tijms at gmail.com>
> wrote:
> >>> Hi,
> >>>
> >>> It looks like that after WFLY-5298 (this commit specifically
> >>>
> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6
> )
> >>> HttpServletRequest#authenticate does not longer do anything.
> >>>
> >>> HttpServletRequest#authenticate calls though to
> >>> JASPIAuthenticationMechanism#authenticate.
> >>>
> >>> There it now obtains the attachment that was set by the new
> >>> JASPICInitialHandler, which calls the SAM at the beginning of the
> >>> request. And then uses the stored "isValid" outcome directly, without
> >>> calling the SAM again.
> >>>
> >>> See the code below:
> >>>
> >>>   public AuthenticationMechanismOutcome authenticate(final
> >>> HttpServerExchange exchange, final SecurityContext sc) {
> >>>         JASPICAttachment attachment =
> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
> >>>
> >>>         AuthenticationMechanismOutcome outcome;
> >>>         Account authenticatedAccount = null;
> >>>
> >>>         boolean isValid = attachment.isValid();
> >>>         final ServletRequestContext requestContext =
> >>> attachment.getRequestContext();
> >>>         final JASPIServerAuthenticationManager sam =
> attachment.getSam();
> >>>         final JASPICallbackHandler cbh = attachment.getCbh();
> >>>
> >>>         GenericMessageInfo messageInfo = attachment.getMessageInfo();
> >>>         if (isValid) {
> >>>             // The CBH filled in the JBOSS SecurityContext, we need to
> >>> create an Undertow account based on that
> >>>             org.jboss.security.SecurityContext jbossSct =
> >>> SecurityActions.getSecurityContext();
> >>>             authenticatedAccount =
> >>> createAccount(attachment.getCachedAccount(), jbossSct);
> >>>         }
> >>>
> >>> This is not correct I think. The code should call the SAM once again
> >>> and use the outcome from that call.
> >>>
> >>> Am I missing something, or was the new call to the SAM simply
> >>> forgotten at this point?
> >>>
> >>> Kind regards,
> >>> Arjan Tijms
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150927/13fedf33/attachment-0001.html 

From jason.greene at redhat.com  Sun Sep 27 19:54:52 2015
From: jason.greene at redhat.com (Jason T. Greene)
Date: Sun, 27 Sep 2015 19:54:52 -0400 (EDT)
Subject: [wildfly-dev] Regression after WFLY-5298;
	request#authenticate does nothing now
In-Reply-To: <CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
Message-ID: <D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>

The MIT license also grants the ability to relicense.

> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
> 
> This was deliberately disabled to match the behavior of EAP6. It can be controlled by the proactive-authentication attribute on the servlet container. These JAPIC changes have been driven by this change, in order to get the TCK to pass without proactive auth. I will look into it today.
> 
> If you can contribute your tests it would be greatly appreciated, we do not have much coverage (and apparently neither does the TCK, as it does not pick up these issues). As I understand it if you are the sole author you retain copyright and can re-license them under whatever license you like. 
> 
> Stuart
> 
>> On Sat, 26 Sep 2015 at 01:15 arjan tijms <arjan.tijms at gmail.com> wrote:
>> Hi,
>> 
>> I discovered some more issues originating from 5298:
>> 
>> pre-emptive authentication on a public page doesn't work anymore
>> either. It still worked fine in WildFly 9.0.1.
>> 
>> This can be easily seen when running the JASPIC tests from
>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>> 
>> For the basic authentication tests, the following now fail:
>> 
>> Failed tests:
>>   testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>   testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>> 
>> These tests don't rely on request#authenticate, but depend on
>> automatic calling of a SAM at the beginning of a request. After manual
>> inspection it's clear that the SAM is called, but its outcome is not
>> being applied.
>> 
>> Kind regards,
>> Arjan
>> 
>> 
>> 
>> 
>> 
>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
>> > Hi,
>> >
>> > I checked again on the just released WildFly 10.0 CR2, but
>> > unfortunately the code is still severely broken now.
>> >
>> > There are two main issues, and they're both in this fragment in
>> > JASPIAuthenticationMechanism:
>> >
>> > if(isValid == null) {
>> >     isValid = createJASPIAuthenticationManager().isValid(messageInfo,
>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>> > attachment.getApplicationIdentifier(), new JBossCallbackHandler());
>> > }
>> >
>> > The first problem is the "isValid == null" check. After the first call
>> > to request#authenticate in a given request this will always be
>> > non-null. The result is that a request for programmatic authentication
>> > will effectively be ignored the first time.
>> >
>> > The second problem is that this passes in the JBossCallbackHandler,
>> > but this doesn't know how to handle JASPIC callbacks and this will
>> > result in an exception like the following:
>> >
>> > javax.security.auth.callback.UnsupportedCallbackException: PBOX00014:
>> > org.jboss.security.auth.callback.JBossCallbackHandler does not handle
>> > a callback of type
>> > javax.security.auth.message.callback.CallerPrincipalCallback
>> >     at org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>> >     at org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>> >
>> > The code should pass in a JASPICallbackHandler here.
>> >
>> > Hope this can be fixed. Perhaps it's just a matter of removing the
>> > "isValid == null" check and passing in the right callback handler.
>> >
>> > Kind regards,
>> > Arjan Tijms
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
>> >> p.s. if I just revert JASPIAuthenticationMechanism to the previous
>> >> version, but leaving in the new JASPICInitialHandler, then everything
>> >> seems to work again. This is a bit of hacky workaround perhaps, but in
>> >> some quick testing it does do the trick.
>> >>
>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <arjan.tijms at gmail.com> wrote:
>> >>> Hi,
>> >>>
>> >>> It looks like that after WFLY-5298 (this commit specifically
>> >>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6)
>> >>> HttpServletRequest#authenticate does not longer do anything.
>> >>>
>> >>> HttpServletRequest#authenticate calls though to
>> >>> JASPIAuthenticationMechanism#authenticate.
>> >>>
>> >>> There it now obtains the attachment that was set by the new
>> >>> JASPICInitialHandler, which calls the SAM at the beginning of the
>> >>> request. And then uses the stored "isValid" outcome directly, without
>> >>> calling the SAM again.
>> >>>
>> >>> See the code below:
>> >>>
>> >>>   public AuthenticationMechanismOutcome authenticate(final
>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>> >>>         JASPICAttachment attachment =
>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>> >>>
>> >>>         AuthenticationMechanismOutcome outcome;
>> >>>         Account authenticatedAccount = null;
>> >>>
>> >>>         boolean isValid = attachment.isValid();
>> >>>         final ServletRequestContext requestContext =
>> >>> attachment.getRequestContext();
>> >>>         final JASPIServerAuthenticationManager sam = attachment.getSam();
>> >>>         final JASPICallbackHandler cbh = attachment.getCbh();
>> >>>
>> >>>         GenericMessageInfo messageInfo = attachment.getMessageInfo();
>> >>>         if (isValid) {
>> >>>             // The CBH filled in the JBOSS SecurityContext, we need to
>> >>> create an Undertow account based on that
>> >>>             org.jboss.security.SecurityContext jbossSct =
>> >>> SecurityActions.getSecurityContext();
>> >>>             authenticatedAccount =
>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>> >>>         }
>> >>>
>> >>> This is not correct I think. The code should call the SAM once again
>> >>> and use the outcome from that call.
>> >>>
>> >>> Am I missing something, or was the new call to the SAM simply
>> >>> forgotten at this point?
>> >>>
>> >>> Kind regards,
>> >>> Arjan Tijms
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150927/93342fcc/attachment.html 

From stuart.w.douglas at gmail.com  Mon Sep 28 01:49:15 2015
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Mon, 28 Sep 2015 05:49:15 +0000
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
	<D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
Message-ID: <CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>

Can you verify that this PR: https://github.com/wildfly/wildfly/pull/8204
fixes your issues?

Basically it reverts the recent changes, and instead installs a handler
after authenticate to handle requests that do not require authentication.

Stuart

On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <jason.greene at redhat.com>
wrote:

> The MIT license also grants the ability to relicense.
>
> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <stuart.w.douglas at gmail.com>
> wrote:
>
> This was deliberately disabled to match the behavior of EAP6. It can be
> controlled by the proactive-authentication attribute on the servlet
> container. These JAPIC changes have been driven by this change, in order to
> get the TCK to pass without proactive auth. I will look into it today.
>
> If you can contribute your tests it would be greatly appreciated, we do
> not have much coverage (and apparently neither does the TCK, as it does not
> pick up these issues). As I understand it if you are the sole author you
> retain copyright and can re-license them under whatever license you like.
>
> Stuart
>
> On Sat, 26 Sep 2015 at 01:15 arjan tijms <arjan.tijms at gmail.com> wrote:
>
>> Hi,
>>
>> I discovered some more issues originating from 5298:
>>
>> pre-emptive authentication on a public page doesn't work anymore
>> either. It still worked fine in WildFly 9.0.1.
>>
>> This can be easily seen when running the JASPIC tests from
>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>
>> For the basic authentication tests, the following now fail:
>>
>> Failed tests:
>>
>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>
>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>
>> These tests don't rely on request#authenticate, but depend on
>> automatic calling of a SAM at the beginning of a request. After manual
>> inspection it's clear that the SAM is called, but its outcome is not
>> being applied.
>>
>> Kind regards,
>> Arjan
>>
>>
>>
>>
>>
>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > I checked again on the just released WildFly 10.0 CR2, but
>> > unfortunately the code is still severely broken now.
>> >
>> > There are two main issues, and they're both in this fragment in
>> > JASPIAuthenticationMechanism:
>> >
>> > if(isValid == null) {
>> >     isValid = createJASPIAuthenticationManager().isValid(messageInfo,
>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>> > attachment.getApplicationIdentifier(), new JBossCallbackHandler());
>> > }
>> >
>> > The first problem is the "isValid == null" check. After the first call
>> > to request#authenticate in a given request this will always be
>> > non-null. The result is that a request for programmatic authentication
>> > will effectively be ignored the first time.
>> >
>> > The second problem is that this passes in the JBossCallbackHandler,
>> > but this doesn't know how to handle JASPIC callbacks and this will
>> > result in an exception like the following:
>> >
>> > javax.security.auth.callback.UnsupportedCallbackException: PBOX00014:
>> > org.jboss.security.auth.callback.JBossCallbackHandler does not handle
>> > a callback of type
>> > javax.security.auth.message.callback.CallerPrincipalCallback
>> >     at
>> org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>> >     at
>> org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>> >
>> > The code should pass in a JASPICallbackHandler here.
>> >
>> > Hope this can be fixed. Perhaps it's just a matter of removing the
>> > "isValid == null" check and passing in the right callback handler.
>> >
>> > Kind regards,
>> > Arjan Tijms
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>> >> p.s. if I just revert JASPIAuthenticationMechanism to the previous
>> >> version, but leaving in the new JASPICInitialHandler, then everything
>> >> seems to work again. This is a bit of hacky workaround perhaps, but in
>> >> some quick testing it does do the trick.
>> >>
>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>> >>> Hi,
>> >>>
>> >>> It looks like that after WFLY-5298 (this commit specifically
>> >>>
>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6
>> )
>> >>> HttpServletRequest#authenticate does not longer do anything.
>> >>>
>> >>> HttpServletRequest#authenticate calls though to
>> >>> JASPIAuthenticationMechanism#authenticate.
>> >>>
>> >>> There it now obtains the attachment that was set by the new
>> >>> JASPICInitialHandler, which calls the SAM at the beginning of the
>> >>> request. And then uses the stored "isValid" outcome directly, without
>> >>> calling the SAM again.
>> >>>
>> >>> See the code below:
>> >>>
>> >>>   public AuthenticationMechanismOutcome authenticate(final
>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>> >>>         JASPICAttachment attachment =
>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>> >>>
>> >>>         AuthenticationMechanismOutcome outcome;
>> >>>         Account authenticatedAccount = null;
>> >>>
>> >>>         boolean isValid = attachment.isValid();
>> >>>         final ServletRequestContext requestContext =
>> >>> attachment.getRequestContext();
>> >>>         final JASPIServerAuthenticationManager sam =
>> attachment.getSam();
>> >>>         final JASPICallbackHandler cbh = attachment.getCbh();
>> >>>
>> >>>         GenericMessageInfo messageInfo = attachment.getMessageInfo();
>> >>>         if (isValid) {
>> >>>             // The CBH filled in the JBOSS SecurityContext, we need to
>> >>> create an Undertow account based on that
>> >>>             org.jboss.security.SecurityContext jbossSct =
>> >>> SecurityActions.getSecurityContext();
>> >>>             authenticatedAccount =
>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>> >>>         }
>> >>>
>> >>> This is not correct I think. The code should call the SAM once again
>> >>> and use the outcome from that call.
>> >>>
>> >>> Am I missing something, or was the new call to the SAM simply
>> >>> forgotten at this point?
>> >>>
>> >>> Kind regards,
>> >>> Arjan Tijms
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150928/b8eb8484/attachment-0001.html 

From arjan.tijms at gmail.com  Mon Sep 28 04:41:16 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 28 Sep 2015 10:41:16 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
	<D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
	<CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
Message-ID: <CAE=-AhAqxcR5CAkUSc24B=-X=oStiKoF3jNaKvaCi9=Me=vtTA@mail.gmail.com>

Hi,

On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas
<stuart.w.douglas at gmail.com> wrote:
> Can you verify that this PR: https://github.com/wildfly/wildfly/pull/8204
> fixes your issues?

I'll look into this as soon as I get the chance today, thanks!

From arjan.tijms at gmail.com  Mon Sep 28 05:09:36 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 28 Sep 2015 11:09:36 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
Message-ID: <CAE=-AhDhT6OFrHtoz0pH9Ry5rpt+-W=jf8u3Q2G19OzSh4huyQ@mail.gmail.com>

Hi,

On Mon, Sep 28, 2015 at 1:49 AM, Stuart Douglas
<stuart.w.douglas at gmail.com> wrote:
> This was deliberately disabled to match the behavior of EAP6. It can be
> controlled by the proactive-authentication attribute on the servlet
> container. These JAPIC changes have been driven by this change, in order to
> get the TCK to pass without proactive auth. I will look into it today.

I understand, the JBoss proprietary authentication (as implemented by
the JBoss Web/Tomcat valves) had a different behaviour. Quite a number
of proprietary mechanisms in containers only call authentication
modules for protected resources.

For JASPIC however this is different and a SAM's validateRequest and
secureResponse always have to be called for every request (protected
or not), in addition to responding to explicit calls to
request#authenticate.

If I'm not mistaken, the "automatic" call to secureResponse was one of
the tests failing in WildFly 9, which 5298 seemed to address.


> If you can contribute your tests it would be greatly appreciated, we do not
> have much coverage (and apparently neither does the TCK, as it does not pick
> up these issues).

Indeed, the TCK for EE 6 and EE 7 (JASPIC 1.0 and JASPIC 1.1
respectively) don't test much. In fact, if you didn't actually
implement JASPIC but just provided stubs for all types with no
implementation code, you could pass the TCK as well (one
implementation got certified that way). I've been in contact with the
TCK engineer and for EE 8 the situation will be improved (at least a
little, hopefully a lot).

> As I understand it if you are the sole author you retain
> copyright and can re-license them under whatever license you like.

Okay, I'm personally okay with whatever license for these tests. In
order to keep the tests consistent and only do updates at one place it
would be best if you "just' executed the existing tests. If this is
hard though I can look into porting them to the WildFly test harness.

Note that there are still a couple of tests that need to be added. The
ability to call request#authenticate multiple times (including after a
failure) and the ability to write to the response from secureResponse
aren't tested now. I believe at least WildFly 8 wasn't able to write
to the response from secureResponse (no error or exception, but no
output either). If you're looking at handling secureResponse now this
may be something to look at as well.

Kind regards,
Arjan Tijms




>
> Stuart
>
> On Sat, 26 Sep 2015 at 01:15 arjan tijms <arjan.tijms at gmail.com> wrote:
>>
>> Hi,
>>
>> I discovered some more issues originating from 5298:
>>
>> pre-emptive authentication on a public page doesn't work anymore
>> either. It still worked fine in WildFly 9.0.1.
>>
>> This can be easily seen when running the JASPIC tests from
>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>
>> For the basic authentication tests, the following now fail:
>>
>> Failed tests:
>>
>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>
>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>
>> These tests don't rely on request#authenticate, but depend on
>> automatic calling of a SAM at the beginning of a request. After manual
>> inspection it's clear that the SAM is called, but its outcome is not
>> being applied.
>>
>> Kind regards,
>> Arjan
>>
>>
>>
>>
>>
>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <arjan.tijms at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > I checked again on the just released WildFly 10.0 CR2, but
>> > unfortunately the code is still severely broken now.
>> >
>> > There are two main issues, and they're both in this fragment in
>> > JASPIAuthenticationMechanism:
>> >
>> > if(isValid == null) {
>> >     isValid = createJASPIAuthenticationManager().isValid(messageInfo,
>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>> > attachment.getApplicationIdentifier(), new JBossCallbackHandler());
>> > }
>> >
>> > The first problem is the "isValid == null" check. After the first call
>> > to request#authenticate in a given request this will always be
>> > non-null. The result is that a request for programmatic authentication
>> > will effectively be ignored the first time.
>> >
>> > The second problem is that this passes in the JBossCallbackHandler,
>> > but this doesn't know how to handle JASPIC callbacks and this will
>> > result in an exception like the following:
>> >
>> > javax.security.auth.callback.UnsupportedCallbackException: PBOX00014:
>> > org.jboss.security.auth.callback.JBossCallbackHandler does not handle
>> > a callback of type
>> > javax.security.auth.message.callback.CallerPrincipalCallback
>> >     at
>> > org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>> >     at
>> > org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>> >
>> > The code should pass in a JASPICallbackHandler here.
>> >
>> > Hope this can be fixed. Perhaps it's just a matter of removing the
>> > "isValid == null" check and passing in the right callback handler.
>> >
>> > Kind regards,
>> > Arjan Tijms
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <arjan.tijms at gmail.com>
>> > wrote:
>> >> p.s. if I just revert JASPIAuthenticationMechanism to the previous
>> >> version, but leaving in the new JASPICInitialHandler, then everything
>> >> seems to work again. This is a bit of hacky workaround perhaps, but in
>> >> some quick testing it does do the trick.
>> >>
>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <arjan.tijms at gmail.com>
>> >> wrote:
>> >>> Hi,
>> >>>
>> >>> It looks like that after WFLY-5298 (this commit specifically
>> >>>
>> >>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6)
>> >>> HttpServletRequest#authenticate does not longer do anything.
>> >>>
>> >>> HttpServletRequest#authenticate calls though to
>> >>> JASPIAuthenticationMechanism#authenticate.
>> >>>
>> >>> There it now obtains the attachment that was set by the new
>> >>> JASPICInitialHandler, which calls the SAM at the beginning of the
>> >>> request. And then uses the stored "isValid" outcome directly, without
>> >>> calling the SAM again.
>> >>>
>> >>> See the code below:
>> >>>
>> >>>   public AuthenticationMechanismOutcome authenticate(final
>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>> >>>         JASPICAttachment attachment =
>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>> >>>
>> >>>         AuthenticationMechanismOutcome outcome;
>> >>>         Account authenticatedAccount = null;
>> >>>
>> >>>         boolean isValid = attachment.isValid();
>> >>>         final ServletRequestContext requestContext =
>> >>> attachment.getRequestContext();
>> >>>         final JASPIServerAuthenticationManager sam =
>> >>> attachment.getSam();
>> >>>         final JASPICallbackHandler cbh = attachment.getCbh();
>> >>>
>> >>>         GenericMessageInfo messageInfo = attachment.getMessageInfo();
>> >>>         if (isValid) {
>> >>>             // The CBH filled in the JBOSS SecurityContext, we need to
>> >>> create an Undertow account based on that
>> >>>             org.jboss.security.SecurityContext jbossSct =
>> >>> SecurityActions.getSecurityContext();
>> >>>             authenticatedAccount =
>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>> >>>         }
>> >>>
>> >>> This is not correct I think. The code should call the SAM once again
>> >>> and use the outcome from that call.
>> >>>
>> >>> Am I missing something, or was the new call to the SAM simply
>> >>> forgotten at this point?
>> >>>
>> >>> Kind regards,
>> >>> Arjan Tijms
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From alexey.loubyansky at redhat.com  Mon Sep 28 08:06:22 2015
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Mon, 28 Sep 2015 14:06:22 +0200
Subject: [wildfly-dev] issues with IBM JVM on Linux
In-Reply-To: <914C3086-2A71-457B-8C55-77D1CFF4C778@gmx.ch>
References: <56054753.7050706@redhat.com> <560549B5.6080308@redhat.com>
	<560578D8.1090200@redhat.com>
	<914C3086-2A71-457B-8C55-77D1CFF4C778@gmx.ch>
Message-ID: <56092D3E.7050106@redhat.com>

Thanks. I tried -Xnojit (the tests did take significantly more time to 
complete) but it didn't affect the results. The testsuite failed 3 times 
out of 5 runs with the same errors.

Alexey

On 09/25/2015 08:14 PM, Radoslaw Rodak wrote:
> Hi
>
> Few months ago I had pretty similar issue on IBM JDK , but version 1.7.0 .
>
> Doing 10 time same xslt transformation randomly it was failing.
>
> Problem was JIT Compiler Bug in IBM JDK?. issue was fix in newer Version of IBM JDK.
> Best ist to get newest IBM JDK Version.
>
> Work Arround for me on IBM JDK was to use  TransformerFactory , which is used as default on Oracle JDK on Linux and Windows, which is not the case on IBM JDK...:
>
> -Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl
>
> To see if the error is really because of IBM JIT ( begin of this year IBM JDK had a lot of JIT bugfixes? ) you can also just turn off JIT ( -Xnojit ) and see if the problem still happened ( side effect test will run very slow )
>
> P.S:
>
> Interesting side Effect was, transformation was 50% faster with Xalan Implementation compared to default IBM TransformerFactory ?
>
> Cheers
> Radek
>
> Am 25.09.2015 um 18:39 schrieb Alexey Loubyansky <alexey.loubyansky at redhat.com>:
>
>> On 09/25/2015 03:18 PM, Scott Marlow wrote:
>>> Are you using the latest JVM?  From [1], it looks like the last update
>>> was on July 17th 2015.
>>
>> No, I've been using the one we have installed in brontes to be able to
>> reproduce.
>>
>> But I've tried the latest and it still fails occasionally although less
>> often: once or twice in 10 runs. So it appears to be better than the one
>> we've been using. Tomaz is going to upgrade it.
>>
>>> Does it make a difference whether the classes were generated by the IBM
>>> versus Oracle versus OpenJDK compiler?
>>
>> Haven't tried that yet.
>>
>> Thanks,
>> Alexey
>>
>>> Scott
>>>
>>> [1] http://www.ibm.com/developerworks/java/jdk/linux/download.html
>>>
>>> On 09/25/2015 09:08 AM, Alexey Loubyansky wrote:
>>>> I've been trying to narrow down sporadic failures in the wfcore patching
>>>> tests on the IBM JVM on Linux (version info below) for the last few
>>>> days. I wanted to share this because what I see doesn't make sense to
>>>> me. And I am not sure whether other modules have similar issues.
>>>>
>>>> So, in patching tests the (sporadic) problem appears when parsing XML
>>>> attributes. E.g. if there is an element with attributes 'name' and
>>>> 'add-on', sometimes the value of name will end up containing the value
>>>> of add-on attribute. Here is the actual code for this (Attribute is an
>>>> enum) from org.jboss.as.patching.metadata.PatchXmlUtils:
>>>>
>>>> String name = null;
>>>> boolean isAddOn = false;
>>>> final int count = reader.getAttributeCount();
>>>> for (int i = 0; i < count; i++) {
>>>>        final String value = reader.getAttributeValue(i);
>>>>        final Attribute attribute =
>>>> Attribute.forName(reader.getAttributeLocalName(i));
>>>>        if(Attribute.NAME == attribute) {
>>>>            name = value;
>>>>        } else if (Attribute.ADD_ON == attribute) {
>>>>            isAddOn = Boolean.valueOf(value);
>>>>        } else {
>>>>            throw unexpectedAttribute(reader, i);
>>>>        }
>>>> }
>>>>
>>>> So, sometimes the tests fail because the value of name is 'true',
>>>> apparently. This is just one example. It affects parsing attributes in
>>>> general in this class.
>>>>
>>>> I noticed that if I do anything with variable 'value' in the loop (or
>>>> pass it as an argument to some method and actually do something with it
>>>> in that method), e.g. System.err.println("value=" + value); the problem
>>>> goes away.
>>>>
>>>> Another workaround I've found is to inline the variable, i.e. use
>>>> reader.getAttributeValue(i) directly instead of using a variable.
>>>>
>>>> By the "problem goes away" I mean that I haven't seen these kind of
>>>> failures anymore with the changes I mentioned. To give some statistics,
>>>> with the original code the tests would fail from 2 to 5 times out of 10
>>>> runs.
>>>> With the inlined variable value they pass 100%. I've be running them for
>>>> 3 days now.
>>>>
>>>> Here is the JVM info.
>>>>
>>>> java version "1.8.0"
>>>> Java(TM) SE Runtime Environment (build pxi3280-20150129_02)
>>>> IBM J9 VM (build 2.8, JRE 1.8.0 Linux x86-32 20150116_231420 (JIT
>>>> enabled, AOT enabled)
>>>> J9VM - R28_Java8_GA_20150116_2030_B231420
>>>> JIT  - tr.r14.java_20150109_82886.02
>>>> GC   - R28_Java8_GA_20150116_2030_B231420
>>>> J9CL - 20150116_231420)
>>>> JCL - 20150123_01 based on Oracle jdk8u31-b12
>>>>
>>>>
>>>> Any ideas or suggestions?
>>>>
>>>>
>>>> Thanks,
>>>> Alexey
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From arjan.tijms at gmail.com  Mon Sep 28 10:58:13 2015
From: arjan.tijms at gmail.com (arjan tijms)
Date: Mon, 28 Sep 2015 16:58:13 +0200
Subject: [wildfly-dev] Regression after WFLY-5298;
 request#authenticate does nothing now
In-Reply-To: <CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
References: <CAE=-AhAtCRdEtjnKTTXDt2CXhRXkDrWQnZX0k-Zr+h1vqt0diA@mail.gmail.com>
	<CAE=-AhCDk2c2xgYWYTWfoCuwZPGnE7qJxa2Dujwfa=m4BTZ_GQ@mail.gmail.com>
	<CAE=-AhAcyjm6z1GKYxehBhvZN+QLkEFMRF5njqo4WvnBR+vL5Q@mail.gmail.com>
	<CAE=-AhBgrQrAK=zWvZ=n+Wd-Q1rHia6JnGfBVjL5NLfYi-PVhQ@mail.gmail.com>
	<CAAoo=c6aTNPs28HhnhHCGSB8e=pbruyFNxMaSvnJ0ZRYOs_M5w@mail.gmail.com>
	<D46C1880-C949-423D-B950-54F393ACA5D5@redhat.com>
	<CAAoo=c41k76gcALc3OsZoLJXzMYJmoqrR6PmWk3t1RvYaHf4Ug@mail.gmail.com>
Message-ID: <CAE=-AhBJDVYsTMXdsfXrrJYahBZwB5VoOmpWXgNKr0c+jF1z2A@mail.gmail.com>

Hi,

On Mon, Sep 28, 2015 at 7:49 AM, Stuart Douglas
<stuart.w.douglas at gmail.com> wrote:
> Can you verify that this PR: https://github.com/wildfly/wildfly/pull/8204
> fixes your issues?

I did a quick test run, but now really everything breaks.

In UndertowDeploymentInfoService the following line occurs:

 deploymentInfo.setJaspiAuthenticationMechanism(new
JASPIAuthenticationMechanism(authMethod, securityDomain));

But the constructor arguments are reversed.

The arguments are defined as:

 public JASPIAuthenticationMechanism(final String securityDomain,
final String configuredAuthMethod) {

When I reverse the arguments to their correct order, the same tests as
before fail unfortunately.

This individual case can be rather easily debugged manually by cloning
the project using Eclipse/JBoss tools from
https://github.com/javaee-samples/javaee7-samples Then importing just
the jaspic and test-utils directories as Maven projects, and then
deploying "jaspic-basic-authentication" using Add and Remove on the
server.

If you then request:

http://localhost:8080/jaspic-basic-authentication/public/servlet?doLogin

You should see the same output as:

http://localhost:8080/jaspic-basic-authentication/protected/servlet?doLogin

Hope this helps

Kind regards,
Arjan Tijms







>
> Basically it reverts the recent changes, and instead installs a handler
> after authenticate to handle requests that do not require authentication.
>
> Stuart
>
> On Mon, 28 Sep 2015 at 09:54 Jason T. Greene <jason.greene at redhat.com>
> wrote:
>>
>> The MIT license also grants the ability to relicense.
>>
>> On Sep 27, 2015, at 6:50 PM, Stuart Douglas <stuart.w.douglas at gmail.com>
>> wrote:
>>
>> This was deliberately disabled to match the behavior of EAP6. It can be
>> controlled by the proactive-authentication attribute on the servlet
>> container. These JAPIC changes have been driven by this change, in order to
>> get the TCK to pass without proactive auth. I will look into it today.
>>
>> If you can contribute your tests it would be greatly appreciated, we do
>> not have much coverage (and apparently neither does the TCK, as it does not
>> pick up these issues). As I understand it if you are the sole author you
>> retain copyright and can re-license them under whatever license you like.
>>
>> Stuart
>>
>> On Sat, 26 Sep 2015 at 01:15 arjan tijms <arjan.tijms at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> I discovered some more issues originating from 5298:
>>>
>>> pre-emptive authentication on a public page doesn't work anymore
>>> either. It still worked fine in WildFly 9.0.1.
>>>
>>> This can be easily seen when running the JASPIC tests from
>>> https://github.com/javaee-samples/javaee7-samples/tree/master/jaspic
>>>
>>> For the basic authentication tests, the following now fail:
>>>
>>> Failed tests:
>>>
>>> testPublicPageNotRememberLogin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>
>>> testPublicPageLoggedin(org.javaee7.jaspic.basicauthentication.BasicAuthenticationPublicTest)
>>>
>>> These tests don't rely on request#authenticate, but depend on
>>> automatic calling of a SAM at the beginning of a request. After manual
>>> inspection it's clear that the SAM is called, but its outcome is not
>>> being applied.
>>>
>>> Kind regards,
>>> Arjan
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Sep 25, 2015 at 3:18 PM, arjan tijms <arjan.tijms at gmail.com>
>>> wrote:
>>> > Hi,
>>> >
>>> > I checked again on the just released WildFly 10.0 CR2, but
>>> > unfortunately the code is still severely broken now.
>>> >
>>> > There are two main issues, and they're both in this fragment in
>>> > JASPIAuthenticationMechanism:
>>> >
>>> > if(isValid == null) {
>>> >     isValid = createJASPIAuthenticationManager().isValid(messageInfo,
>>> > new Subject(), JASPI_HTTP_SERVLET_LAYER,
>>> > attachment.getApplicationIdentifier(), new JBossCallbackHandler());
>>> > }
>>> >
>>> > The first problem is the "isValid == null" check. After the first call
>>> > to request#authenticate in a given request this will always be
>>> > non-null. The result is that a request for programmatic authentication
>>> > will effectively be ignored the first time.
>>> >
>>> > The second problem is that this passes in the JBossCallbackHandler,
>>> > but this doesn't know how to handle JASPIC callbacks and this will
>>> > result in an exception like the following:
>>> >
>>> > javax.security.auth.callback.UnsupportedCallbackException: PBOX00014:
>>> > org.jboss.security.auth.callback.JBossCallbackHandler does not handle
>>> > a callback of type
>>> > javax.security.auth.message.callback.CallerPrincipalCallback
>>> >     at
>>> > org.jboss.security.auth.callback.JBossCallbackHandler.handleCallBack(JBossCallbackHandler.java:138)
>>> >     at
>>> > org.jboss.security.auth.callback.JBossCallbackHandler.handle(JBossCallbackHandler.java:87)
>>> >
>>> > The code should pass in a JASPICallbackHandler here.
>>> >
>>> > Hope this can be fixed. Perhaps it's just a matter of removing the
>>> > "isValid == null" check and passing in the right callback handler.
>>> >
>>> > Kind regards,
>>> > Arjan Tijms
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Wed, Sep 23, 2015 at 5:58 PM, arjan tijms <arjan.tijms at gmail.com>
>>> > wrote:
>>> >> p.s. if I just revert JASPIAuthenticationMechanism to the previous
>>> >> version, but leaving in the new JASPICInitialHandler, then everything
>>> >> seems to work again. This is a bit of hacky workaround perhaps, but in
>>> >> some quick testing it does do the trick.
>>> >>
>>> >> On Wed, Sep 23, 2015 at 3:31 PM, arjan tijms <arjan.tijms at gmail.com>
>>> >> wrote:
>>> >>> Hi,
>>> >>>
>>> >>> It looks like that after WFLY-5298 (this commit specifically
>>> >>>
>>> >>> https://github.com/wildfly/wildfly/commit/121a305c59c3619bb747681c62d099dfddd82709#diff-540388fb45365d1d79353d8b4552bcf6)
>>> >>> HttpServletRequest#authenticate does not longer do anything.
>>> >>>
>>> >>> HttpServletRequest#authenticate calls though to
>>> >>> JASPIAuthenticationMechanism#authenticate.
>>> >>>
>>> >>> There it now obtains the attachment that was set by the new
>>> >>> JASPICInitialHandler, which calls the SAM at the beginning of the
>>> >>> request. And then uses the stored "isValid" outcome directly, without
>>> >>> calling the SAM again.
>>> >>>
>>> >>> See the code below:
>>> >>>
>>> >>>   public AuthenticationMechanismOutcome authenticate(final
>>> >>> HttpServerExchange exchange, final SecurityContext sc) {
>>> >>>         JASPICAttachment attachment =
>>> >>> exchange.getAttachment(JASPICAttachment.ATTACHMENT_KEY);
>>> >>>
>>> >>>         AuthenticationMechanismOutcome outcome;
>>> >>>         Account authenticatedAccount = null;
>>> >>>
>>> >>>         boolean isValid = attachment.isValid();
>>> >>>         final ServletRequestContext requestContext =
>>> >>> attachment.getRequestContext();
>>> >>>         final JASPIServerAuthenticationManager sam =
>>> >>> attachment.getSam();
>>> >>>         final JASPICallbackHandler cbh = attachment.getCbh();
>>> >>>
>>> >>>         GenericMessageInfo messageInfo = attachment.getMessageInfo();
>>> >>>         if (isValid) {
>>> >>>             // The CBH filled in the JBOSS SecurityContext, we need
>>> >>> to
>>> >>> create an Undertow account based on that
>>> >>>             org.jboss.security.SecurityContext jbossSct =
>>> >>> SecurityActions.getSecurityContext();
>>> >>>             authenticatedAccount =
>>> >>> createAccount(attachment.getCachedAccount(), jbossSct);
>>> >>>         }
>>> >>>
>>> >>> This is not correct I think. The code should call the SAM once again
>>> >>> and use the outcome from that call.
>>> >>>
>>> >>> Am I missing something, or was the new call to the SAM simply
>>> >>> forgotten at this point?
>>> >>>
>>> >>> Kind regards,
>>> >>> Arjan Tijms
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From tomaz.cerar at gmail.com  Tue Sep 29 11:29:42 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 29 Sep 2015 17:29:42 +0200
Subject: [wildfly-dev] Powershell scripts
Message-ID: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>

Hey guys,


just heads up, I've managed to prepare[1] all powershell scripts to replace
the aging .bat ones.

New scripts unify most of the shared "code" that all scripts use by
including common.ps1,
and each script only has the code that differs from common behavior they
all share.

As result of move we now have much more reliable and faster scripts that
share common code,
which helps with maintaining a lot.

New scripts (domain.ps1 & standalone.ps1) now support --background (also
controllable via .conf.ps1)
option that runs the process in background and remembers its pid and as
such add support for
feature that until now was only in *nix version of scripts.

I would like to propose this PR for inclusion to WildFly 10. As it doesn't
alter any existing behavior
but just adds & improve the script experience on Windows.

As we get to test and verify that new scripts don't break/include any
currently available option/action
I would also like to remove the batch scripts[2], so they would just do
call out to their .ps1 counter parts.

Once this scripts get merged, I will send PR to also add PS scripts for
WildFly full defined scripts,
given that most of the functionally is already in "common.ps1" new scripts
will be just simple 5 liners [3]


--
tomaz


[1] https://github.com/wildfly/wildfly-core/pull/1118
[2] https://github.com/wildfly/wildfly-core/pull/1126
[3]
https://github.com/ctomc/wildfly-core/blob/powershell/core-feature-pack/src/main/resources/content/bin/add-user.ps1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150929/bad9d023/attachment.html 

From brian.stansberry at redhat.com  Tue Sep 29 11:48:51 2015
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 29 Sep 2015 10:48:51 -0500
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
Message-ID: <560AB2E3.1050602@redhat.com>

Thanks for posting this.

I'm curious if anyone on the list has concerns about the .bat scripts 
now delegating the powershell ones. The advantages are obvious; the 
disadvantages I really don't know.

I only occasionally use Windows in a VM, so I haven't really kept up 
with what is supported in what versions of Windows. I know Powershell 
has been around a long, long time.

On 9/29/15 10:29 AM, Toma? Cerar wrote:
> Hey guys,
>
>
> just heads up, I've managed to prepare[1] all powershell scripts to
> replace the aging .bat ones.
>
> New scripts unify most of the shared "code" that all scripts use by
> including common.ps1,
> and each script only has the code that differs from common behavior they
> all share.
>
> As result of move we now have much more reliable and faster scripts that
> share common code,
> which helps with maintaining a lot.
>
> New scripts (domain.ps1 & standalone.ps1) now support --background (also
> controllable via .conf.ps1)
> option that runs the process in background and remembers its pid and as
> such add support for
> feature that until now was only in *nix version of scripts.
>
> I would like to propose this PR for inclusion to WildFly 10. As it
> doesn't alter any existing behavior
> but just adds & improve the script experience on Windows.
>
> As we get to test and verify that new scripts don't break/include any
> currently available option/action
> I would also like to remove the batch scripts[2], so they would just do
> call out to their .ps1 counter parts.
>
> Once this scripts get merged, I will send PR to also add PS scripts for
> WildFly full defined scripts,
> given that most of the functionally is already in "common.ps1" new
> scripts will be just simple 5 liners [3]
>
>
> --
> tomaz
>
>
> [1] https://github.com/wildfly/wildfly-core/pull/1118
> [2] https://github.com/wildfly/wildfly-core/pull/1126
> [3]
> https://github.com/ctomc/wildfly-core/blob/powershell/core-feature-pack/src/main/resources/content/bin/add-user.ps1
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

From ehugonne at redhat.com  Tue Sep 29 12:08:11 2015
From: ehugonne at redhat.com (Emmanuel Hugonnet)
Date: Tue, 29 Sep 2015 18:08:11 +0200
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <560AB2E3.1050602@redhat.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
	<560AB2E3.1050602@redhat.com>
Message-ID: <560AB76B.3070602@redhat.com>

Hum, it will break my NetBeans plugin as I rely on the shell scripts ;)
I can easily fix this but I vote against removing the bat files this late in the release process.
My 2 cents
Emmanuel


Le 29/09/2015 17:48, Brian Stansberry a ?crit :
> Thanks for posting this.
> 
> I'm curious if anyone on the list has concerns about the .bat scripts 
> now delegating the powershell ones. The advantages are obvious; the 
> disadvantages I really don't know.
> 
> I only occasionally use Windows in a VM, so I haven't really kept up 
> with what is supported in what versions of Windows. I know Powershell 
> has been around a long, long time.
> 
> On 9/29/15 10:29 AM, Toma? Cerar wrote:
>> Hey guys,
>>
>>
>> just heads up, I've managed to prepare[1] all powershell scripts to
>> replace the aging .bat ones.
>>
>> New scripts unify most of the shared "code" that all scripts use by
>> including common.ps1,
>> and each script only has the code that differs from common behavior they
>> all share.
>>
>> As result of move we now have much more reliable and faster scripts that
>> share common code,
>> which helps with maintaining a lot.
>>
>> New scripts (domain.ps1 & standalone.ps1) now support --background (also
>> controllable via .conf.ps1)
>> option that runs the process in background and remembers its pid and as
>> such add support for
>> feature that until now was only in *nix version of scripts.
>>
>> I would like to propose this PR for inclusion to WildFly 10. As it
>> doesn't alter any existing behavior
>> but just adds & improve the script experience on Windows.
>>
>> As we get to test and verify that new scripts don't break/include any
>> currently available option/action
>> I would also like to remove the batch scripts[2], so they would just do
>> call out to their .ps1 counter parts.
>>
>> Once this scripts get merged, I will send PR to also add PS scripts for
>> WildFly full defined scripts,
>> given that most of the functionally is already in "common.ps1" new
>> scripts will be just simple 5 liners [3]
>>
>>
>> --
>> tomaz
>>
>>
>> [1] https://github.com/wildfly/wildfly-core/pull/1118
>> [2] https://github.com/wildfly/wildfly-core/pull/1126
>> [3]
>> https://github.com/ctomc/wildfly-core/blob/powershell/core-feature-pack/src/main/resources/content/bin/add-user.ps1
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150929/1e0331b5/attachment.bin 

From tomaz.cerar at gmail.com  Tue Sep 29 12:17:05 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 29 Sep 2015 18:17:05 +0200
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <560AB2E3.1050602@redhat.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
	<560AB2E3.1050602@redhat.com>
Message-ID: <CAMquZP5o0ag7Hg4-RDpAUhPa5stZzAkvUpzNEkyOKabEe6OEsQ@mail.gmail.com>

On Tue, Sep 29, 2015 at 5:48 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> I only occasionally use Windows in a VM, so I haven't really kept up
> with what is supported in what versions of Windows. I know Powershell
> has been around a long, long time.
>


Tnx for pointing this out, forgot to say anything about that.

PowerShell scripts we have now require powershell v2 as a minimum. (we test
in scripts for that)
To quote wikipedia:

"PowerShell 2.0 is integrated with Windows 7 and Windows Server 2008 R2 and
is released for Windows XP with Service Pack 3,
Windows Server 2003 with Service Pack 2, and Windows Vista with Service
Pack 1"

Which as such works on all version of Windows WildFly works on, even XP
which no longer supported,
as JDK8 doesn't run there anymore.

--
tomaz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150929/412be297/attachment.html 

From tomaz.cerar at gmail.com  Tue Sep 29 12:19:33 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Tue, 29 Sep 2015 18:19:33 +0200
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <560AB76B.3070602@redhat.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
	<560AB2E3.1050602@redhat.com> <560AB76B.3070602@redhat.com>
Message-ID: <CAMquZP4jsVKCSaD4ifiAb=AK_CCmvb87v6ihs0vkLkqEYj-bpw@mail.gmail.com>

On Tue, Sep 29, 2015 at 6:08 PM, Emmanuel Hugonnet <ehugonne at redhat.com>
wrote:

> Hum, it will break my NetBeans plugin as I rely on the shell scripts ;)
> I can easily fix this but I vote against removing the bat files this late
> in the release process.
>


Batch scripts will not be removed completely, they will just call out
powershell scripts.

see an example
https://github.com/ctomc/wildfly-core/blob/powershell-batch/core-feature-pack/src/main/resources/content/bin/standalone.bat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150929/b1ae8327/attachment.html 

From jperkins at redhat.com  Tue Sep 29 16:37:03 2015
From: jperkins at redhat.com (James Perkins)
Date: Tue, 29 Sep 2015 13:37:03 -0700
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
Message-ID: <CADGwLphh6wOX0xS7TJW=-xcfJEKEQAEpZ06jAXtmbpU1r5ZbrA@mail.gmail.com>

I don't know anything about PowerShell scripting, so I'm okay with it as
long as the behavior is the same.

The one concern I do have is with the --background bit. We do create a PID
file for the LAUNCH_IN_BACKGROUND, but it doesn't make sense to me why we
do. That's off topic for this though :) We don't seem to use these files
for anything so I just don't see the point in creating them.

Anyway, the whole PID thing I think needs to be thought about. With the
current behavior in the bash scripts it doesn't exit until the background
process has been stopped. I can't really tell what the PS scripts do with
the launch in background. Does the script exit or pause until the process
is exited?

On Tue, Sep 29, 2015 at 8:29 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

> Hey guys,
>
>
> just heads up, I've managed to prepare[1] all powershell scripts to
> replace the aging .bat ones.
>
> New scripts unify most of the shared "code" that all scripts use by
> including common.ps1,
> and each script only has the code that differs from common behavior they
> all share.
>
> As result of move we now have much more reliable and faster scripts that
> share common code,
> which helps with maintaining a lot.
>
> New scripts (domain.ps1 & standalone.ps1) now support --background (also
> controllable via .conf.ps1)
> option that runs the process in background and remembers its pid and as
> such add support for
> feature that until now was only in *nix version of scripts.
>
> I would like to propose this PR for inclusion to WildFly 10. As it doesn't
> alter any existing behavior
> but just adds & improve the script experience on Windows.
>
> As we get to test and verify that new scripts don't break/include any
> currently available option/action
> I would also like to remove the batch scripts[2], so they would just do
> call out to their .ps1 counter parts.
>
> Once this scripts get merged, I will send PR to also add PS scripts for
> WildFly full defined scripts,
> given that most of the functionally is already in "common.ps1" new scripts
> will be just simple 5 liners [3]
>
>
> --
> tomaz
>
>
> [1] https://github.com/wildfly/wildfly-core/pull/1118
> [2] https://github.com/wildfly/wildfly-core/pull/1126
> [3]
> https://github.com/ctomc/wildfly-core/blob/powershell/core-feature-pack/src/main/resources/content/bin/add-user.ps1
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
James R. Perkins
JBoss by Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150929/e7b8d7d4/attachment-0001.html 

From tomaz.cerar at gmail.com  Tue Sep 29 19:06:27 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 30 Sep 2015 01:06:27 +0200
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <CADGwLphh6wOX0xS7TJW=-xcfJEKEQAEpZ06jAXtmbpU1r5ZbrA@mail.gmail.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
	<CADGwLphh6wOX0xS7TJW=-xcfJEKEQAEpZ06jAXtmbpU1r5ZbrA@mail.gmail.com>
Message-ID: <CAMquZP6bmHs4cUa1sELXy8NxWQQXQ08XN0WwkrRYGYcqrupoaw@mail.gmail.com>

On Tue, Sep 29, 2015 at 10:37 PM, James Perkins <jperkins at redhat.com> wrote:

>
> The one concern I do have is with the --background bit. We do create a PID
> file for the LAUNCH_IN_BACKGROUND, but it doesn't make sense to me why we
> do. That's off topic for this though :) We don't seem to use these files
> for anything so I just don't see the point in creating them.
>
> Anyway, the whole PID thing I think needs to be thought about. With the
> current behavior in the bash scripts it doesn't exit until the background
> process has been stopped. I can't really tell what the PS scripts do with
> the launch in background. Does the script exit or pause until the process
> is exited?
>

the LAUNCH_IN_BACKGROUND & --background do the same thing, only difference
is that one is command line parameter other is in the config file.
We use pid file to check if the process is already running and complain if
is instead of starting the server directly.
Powershell script does exit after background process is started, which
feels like proper behavior.

The current behavior in bash scripts looks bit erratic as Rosta figured out
today that .sh script doesn't exit after it is running in background,
confusing/strangely behaving part of is related to cleaning up the pid
file, which is done bit differently in ps scripts...

But anyhow, lets discuss details on hipchat,

Tomaz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150930/d42a2794/attachment.html 

From manderse at redhat.com  Wed Sep 30 07:24:56 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 30 Sep 2015 13:24:56 +0200
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <560AB76B.3070602@redhat.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
	<560AB2E3.1050602@redhat.com> <560AB76B.3070602@redhat.com>
Message-ID: <263691FF-16A2-47ED-8447-AD86038E13F4@redhat.com>

On 29 Sep 2015, at 18:08, Emmanuel Hugonnet wrote:

> Hum, it will break my NetBeans plugin as I rely on the shell scripts 
> ;)

interesting - all my attempts on using the shell scripts ended with 
misery since they resulted in not being able to reliably stop/start the 
server since we don't get the chance to signal the process to die/stop.

Any info on how you worked around that in Netbeans ?

/max

> I can easily fix this but I vote against removing the bat files this 
> late in the release process.
> My 2 cents
> Emmanuel
>
>
> Le 29/09/2015 17:48, Brian Stansberry a ?crit :
>> Thanks for posting this.
>>
>> I'm curious if anyone on the list has concerns about the .bat scripts
>> now delegating the powershell ones. The advantages are obvious; the
>> disadvantages I really don't know.
>>
>> I only occasionally use Windows in a VM, so I haven't really kept up
>> with what is supported in what versions of Windows. I know Powershell
>> has been around a long, long time.
>>
>> On 9/29/15 10:29 AM, Toma? Cerar wrote:
>>> Hey guys,
>>>
>>>
>>> just heads up, I've managed to prepare[1] all powershell scripts to
>>> replace the aging .bat ones.
>>>
>>> New scripts unify most of the shared "code" that all scripts use by
>>> including common.ps1,
>>> and each script only has the code that differs from common behavior 
>>> they
>>> all share.
>>>
>>> As result of move we now have much more reliable and faster scripts 
>>> that
>>> share common code,
>>> which helps with maintaining a lot.
>>>
>>> New scripts (domain.ps1 & standalone.ps1) now support --background 
>>> (also
>>> controllable via .conf.ps1)
>>> option that runs the process in background and remembers its pid and 
>>> as
>>> such add support for
>>> feature that until now was only in *nix version of scripts.
>>>
>>> I would like to propose this PR for inclusion to WildFly 10. As it
>>> doesn't alter any existing behavior
>>> but just adds & improve the script experience on Windows.
>>>
>>> As we get to test and verify that new scripts don't break/include 
>>> any
>>> currently available option/action
>>> I would also like to remove the batch scripts[2], so they would just 
>>> do
>>> call out to their .ps1 counter parts.
>>>
>>> Once this scripts get merged, I will send PR to also add PS scripts 
>>> for
>>> WildFly full defined scripts,
>>> given that most of the functionally is already in "common.ps1" new
>>> scripts will be just simple 5 liners [3]
>>>
>>>
>>> --
>>> tomaz
>>>
>>>
>>> [1] https://github.com/wildfly/wildfly-core/pull/1118
>>> [2] https://github.com/wildfly/wildfly-core/pull/1126
>>> [3]
>>> https://github.com/ctomc/wildfly-core/blob/powershell/core-feature-pack/src/main/resources/content/bin/add-user.ps1
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


/max
http://about.me/maxandersen


From ehugonne at redhat.com  Wed Sep 30 07:38:39 2015
From: ehugonne at redhat.com (Emmanuel Hugonnet)
Date: Wed, 30 Sep 2015 13:38:39 +0200
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <263691FF-16A2-47ED-8447-AD86038E13F4@redhat.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
	<560AB2E3.1050602@redhat.com> <560AB76B.3070602@redhat.com>
	<263691FF-16A2-47ED-8447-AD86038E13F4@redhat.com>
Message-ID: <560BC9BF.5000200@redhat.com>

To start the process we parse the console output to see if the server has started correctly ( + checking the server state using the
management API).
To stop the process : first I try the management API command then I have some funky code from arquillian (iirc) which kills the
jboss-modules processes.
Emmanuel

Le 30/09/2015 13:24, Max Rydahl Andersen a ?crit :
> On 29 Sep 2015, at 18:08, Emmanuel Hugonnet wrote:
> 
>> Hum, it will break my NetBeans plugin as I rely on the shell scripts ;)
> 
> interesting - all my attempts on using the shell scripts ended with misery since they resulted in not being able to reliably stop/start the
> server since we don't get the chance to signal the process to die/stop.
> 
> Any info on how you worked around that in Netbeans ?
> 
> /max
> 
>> I can easily fix this but I vote against removing the bat files this late in the release process.
>> My 2 cents
>> Emmanuel
>>
>>
>> Le 29/09/2015 17:48, Brian Stansberry a ?crit :
>>> Thanks for posting this.
>>>
>>> I'm curious if anyone on the list has concerns about the .bat scripts
>>> now delegating the powershell ones. The advantages are obvious; the
>>> disadvantages I really don't know.
>>>
>>> I only occasionally use Windows in a VM, so I haven't really kept up
>>> with what is supported in what versions of Windows. I know Powershell
>>> has been around a long, long time.
>>>
>>> On 9/29/15 10:29 AM, Toma? Cerar wrote:
>>>> Hey guys,
>>>>
>>>>
>>>> just heads up, I've managed to prepare[1] all powershell scripts to
>>>> replace the aging .bat ones.
>>>>
>>>> New scripts unify most of the shared "code" that all scripts use by
>>>> including common.ps1,
>>>> and each script only has the code that differs from common behavior they
>>>> all share.
>>>>
>>>> As result of move we now have much more reliable and faster scripts that
>>>> share common code,
>>>> which helps with maintaining a lot.
>>>>
>>>> New scripts (domain.ps1 & standalone.ps1) now support --background (also
>>>> controllable via .conf.ps1)
>>>> option that runs the process in background and remembers its pid and as
>>>> such add support for
>>>> feature that until now was only in *nix version of scripts.
>>>>
>>>> I would like to propose this PR for inclusion to WildFly 10. As it
>>>> doesn't alter any existing behavior
>>>> but just adds & improve the script experience on Windows.
>>>>
>>>> As we get to test and verify that new scripts don't break/include any
>>>> currently available option/action
>>>> I would also like to remove the batch scripts[2], so they would just do
>>>> call out to their .ps1 counter parts.
>>>>
>>>> Once this scripts get merged, I will send PR to also add PS scripts for
>>>> WildFly full defined scripts,
>>>> given that most of the functionally is already in "common.ps1" new
>>>> scripts will be just simple 5 liners [3]
>>>>
>>>>
>>>> -- 
>>>> tomaz
>>>>
>>>>
>>>> [1] https://github.com/wildfly/wildfly-core/pull/1118
>>>> [2] https://github.com/wildfly/wildfly-core/pull/1126
>>>> [3]
>>>> https://github.com/ctomc/wildfly-core/blob/powershell/core-feature-pack/src/main/resources/content/bin/add-user.ps1
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> /max
> http://about.me/maxandersen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150930/8f9561bc/attachment.bin 

From tomaz.cerar at gmail.com  Wed Sep 30 09:05:27 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 30 Sep 2015 15:05:27 +0200
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <560BC9BF.5000200@redhat.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
	<560AB2E3.1050602@redhat.com> <560AB76B.3070602@redhat.com>
	<263691FF-16A2-47ED-8447-AD86038E13F4@redhat.com>
	<560BC9BF.5000200@redhat.com>
Message-ID: <CAMquZP50rhZ9a76_ov=Eh=fEvsuKdv4Uc+K3RD1wnPnYLwqecA@mail.gmail.com>

On Wed, Sep 30, 2015 at 1:38 PM, Emmanuel Hugonnet <ehugonne at redhat.com>
wrote:

> To stop the process : first I try the management API command then I have
> some funky code from arquillian (iirc) which kills the
> jboss-modules processes.
>


you probably mean
https://github.com/wildfly/wildfly-arquillian/blob/master/protocol-jmx/src/main/java/org/jboss/as/arquillian/protocol/jmx/ServerKillerExtension.java
Great thing it works for you :)
This was written by Stuart & me over some discussion in Brno F2F as an
optional feature that we would use in testsuite for our CI
as we had problems with hanging processes.
But it ended up not really useful...

--
tomaz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150930/c9f02789/attachment.html 

From ehugonne at redhat.com  Wed Sep 30 09:09:20 2015
From: ehugonne at redhat.com (Emmanuel Hugonnet)
Date: Wed, 30 Sep 2015 15:09:20 +0200
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <CAMquZP50rhZ9a76_ov=Eh=fEvsuKdv4Uc+K3RD1wnPnYLwqecA@mail.gmail.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
	<560AB2E3.1050602@redhat.com> <560AB76B.3070602@redhat.com>
	<263691FF-16A2-47ED-8447-AD86038E13F4@redhat.com>
	<560BC9BF.5000200@redhat.com>
	<CAMquZP50rhZ9a76_ov=Eh=fEvsuKdv4Uc+K3RD1wnPnYLwqecA@mail.gmail.com>
Message-ID: <560BDF00.90106@redhat.com>

Yes ;)
Well I don't test much on Windows but it works just nice on Linux ;-)


Le 30/09/2015 15:05, Toma? Cerar a ?crit :
> 
> On Wed, Sep 30, 2015 at 1:38 PM, Emmanuel Hugonnet <ehugonne at redhat.com <mailto:ehugonne at redhat.com>> wrote:
> 
>     To stop the process : first I try the management API command then I have some funky code from arquillian (iirc) which kills the
>     jboss-modules processes.
> 
> 
> 
> you probably mean
> https://github.com/wildfly/wildfly-arquillian/blob/master/protocol-jmx/src/main/java/org/jboss/as/arquillian/protocol/jmx/ServerKillerExtension.java
> Great thing it works for you :)
> This was written by Stuart & me over some discussion in Brno F2F as an optional feature that we would use in testsuite for our CI
> as we had problems with hanging processes.
> But it ended up not really useful...
> 
> --
> tomaz
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150930/c95590a8/attachment.bin 

From jperkins at redhat.com  Wed Sep 30 13:42:28 2015
From: jperkins at redhat.com (James Perkins)
Date: Wed, 30 Sep 2015 10:42:28 -0700
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <CAMquZP6bmHs4cUa1sELXy8NxWQQXQ08XN0WwkrRYGYcqrupoaw@mail.gmail.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
	<CADGwLphh6wOX0xS7TJW=-xcfJEKEQAEpZ06jAXtmbpU1r5ZbrA@mail.gmail.com>
	<CAMquZP6bmHs4cUa1sELXy8NxWQQXQ08XN0WwkrRYGYcqrupoaw@mail.gmail.com>
Message-ID: <CADGwLpjAsQ81ODZGb8mJgVALsefbQ9oWfCapZOwY78KAezuPkw@mail.gmail.com>

On Tue, Sep 29, 2015 at 4:06 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>
>
> On Tue, Sep 29, 2015 at 10:37 PM, James Perkins <jperkins at redhat.com> wrote:
>>
>>
>> The one concern I do have is with the --background bit. We do create a PID file for the LAUNCH_IN_BACKGROUND, but it doesn't make sense to me why we do. That's off topic for this though :) We don't seem to use these files for anything so I just don't see the point in creating them.
>>
>> Anyway, the whole PID thing I think needs to be thought about. With the current behavior in the bash scripts it doesn't exit until the background process has been stopped. I can't really tell what the PS scripts do with the launch in background. Does the script exit or pause until the process is exited?
>
>
> the LAUNCH_IN_BACKGROUND & --background do the same thing, only difference is that one is command line parameter other is in the config file.
> We use pid file to check if the process is already running and complain if is instead of starting the server directly.
> Powershell script does exit after background process is started, which feels like proper behavior.

We need to understand why the bash scripts don't exit after a new
process is launched. Yes it feels wrong to me which is why I was
complaining about it on Friday :) That doesn't mean the behavior is
wrong though. It also may make sense to have the bash scripts not exit
and the Powershell scripts exit. We need to try to figure out why it
might be setup like that first before assuming we just need to exit.

>
> The current behavior in bash scripts looks bit erratic as Rosta figured out today that .sh script doesn't exit after it is running in background,
> confusing/strangely behaving part of is related to cleaning up the pid file, which is done bit differently in ps scripts...

Right this is my concern. The behavior is different as the bash
scripts don't exit. They wait for the process to end. Maybe it's
correct to be different, I don't know.

>
> But anyhow, lets discuss details on hipchat,
>
> Tomaz
>
>
>



-- 
James R. Perkins
JBoss by Red Hat


From tomaz.cerar at gmail.com  Wed Sep 30 13:57:58 2015
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Wed, 30 Sep 2015 19:57:58 +0200
Subject: [wildfly-dev] Powershell scripts
In-Reply-To: <CADGwLpjAsQ81ODZGb8mJgVALsefbQ9oWfCapZOwY78KAezuPkw@mail.gmail.com>
References: <CAMquZP631wcqL=1-ZnnKpT1NE1Lj4ORYKfeRqBMHvKevL4RC0A@mail.gmail.com>
	<CADGwLphh6wOX0xS7TJW=-xcfJEKEQAEpZ06jAXtmbpU1r5ZbrA@mail.gmail.com>
	<CAMquZP6bmHs4cUa1sELXy8NxWQQXQ08XN0WwkrRYGYcqrupoaw@mail.gmail.com>
	<CADGwLpjAsQ81ODZGb8mJgVALsefbQ9oWfCapZOwY78KAezuPkw@mail.gmail.com>
Message-ID: <CAMquZP6YmYsbWm4CvM0sLXBaLgkUdvC8XxUR7u18bWPAT6_1JA@mail.gmail.com>

On Wed, Sep 30, 2015 at 7:42 PM, James Perkins <jperkins at redhat.com> wrote:

> Right this is my concern. The behavior is different as the bash
> scripts don't exit. They wait for the process to end. Maybe it's
> correct to be different, I don't know.
>


Yeah, it looks like that LAUNCH_IN_BACKGROUND behavior is pretty much
implemented
to satisfy the init.d script we have and is not really useful if you run it
directly.
If that is really so, I am not a fan of having that in standalone.sh
directly...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20150930/ce72ba31/attachment.html