From belaran at redhat.com  Fri Dec  1 05:11:09 2017
From: belaran at redhat.com (Romain Pelisse)
Date: Fri, 1 Dec 2017 11:11:09 +0100
Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have
 POSIX permissions perfectly set
In-Reply-To: <CAPhbRDZFTd52gO8-psaaXJSVNAPn=3MtjA3XuyEC501Hj-rRJw@mail.gmail.com>
References: <CALuBA_p5Mqag2+TSD9bUWGM5BgDpirdZC7zvL5OE8w-HfA4AWw@mail.gmail.com>
	<CAPhbRDYyGwNpqFq8bYdRk53_hx6Mg4yHwOcmmYYnwDp_3-B+_A@mail.gmail.com>
	<CALuBA_pSvfNYPug1byQrS7Bic45vVvvdQ4Mjd-BQ6Pa4t5m05g@mail.gmail.com>
	<CAPhbRDYnYLd-SXuE_m_2b14W9VwNhy08KDpC0MdP6n3mipMi0A@mail.gmail.com>
	<CAPhbRDZFTd52gO8-psaaXJSVNAPn=3MtjA3XuyEC501Hj-rRJw@mail.gmail.com>
Message-ID: <CALuBA_pXT89PNspojT-sT3GNTVhf1R1F7YJPxn7K-B6dmP4+bg@mail.gmail.com>

Hi Brian and all,

err, my own observation differs from yours. I've rebuild Wildfly from the
last content of the master branch and get the same privileges on the
jboss-modules.jar (so -rw-rw-r-- and not as you are seeing  rwxr--r--).
Same with the domain folder, which turns out on my local system associated
to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a
transcript of what I did - maybe you can spot why our results differs so
much.

$ git show
commit 46e119c65d9e32bc0ec69f3933267fece959ed3f
Merge: 051f080 c7d9075
Author: Kabir Khan <kkhan at redhat.com>
Date:   Tue Nov 28 17:46:40 2017 +0000

    Merge pull request #10669 from praxeo/WFLY-9284

    WFLY-9284 Correct MVN env variable to mvnw.cmd

$ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d wildfly-12.zip
...
$ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
-rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov.  11:41
wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
$ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/  -d
drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov.  11:41
wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/

Checking all the jars in the distribution, they all appears to have the
mask '-rw-rw-r--':

$ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done | sed -e
'/-rw-rw-r--/d'
$

Regarding properties files, here is the exhaustive list of properties that
RPM packaging has modified the privileges of:

appclient/configuration/logging.properties rw-------
domain/configuration/application-roles.properties rw-------
domain/configuration/default-server-logging.properties rw-------
domain/configuration/logging.properties rw-------
domain/configuration/mgmt-groups.properties rw-------
standalone/configuration/application-roles.properties rw-------
standalone/configuration/logging.properties rw-------
standalone/configuration/mgmt-groups.properties rw-------

If I compare that with the content of the extract zip (same fresh built as
above), I can see that 4 files are not having the same mask (rw------):

$ for file in $(cut -f1 -d\  ../../../list-props-files.txt ); do ls -l
$file ; done
-rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
appclient/configuration/logging.properties
-rw-------. 1 rpelisse rpelisse 710 30 nov.  11:41
domain/configuration/application-roles.properties
-rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
domain/configuration/default-server-logging.properties
-rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
domain/configuration/logging.properties
-rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
domain/configuration/mgmt-groups.properties
-rw-------. 1 rpelisse rpelisse 711 30 nov.  11:41
standalone/configuration/application-roles.properties
-rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
standalone/configuration/logging.properties
-rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
standalone/configuration/mgmt-groups.properties

Now, as you said, those files privileges are indeed fine-grained, so maybe
we can push back to people making the RPM for them to NOT change the
following files privileges:

-rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
appclient/configuration/logging.properties
-rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
domain/configuration/default-server-logging.properties
-rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
domain/configuration/logging.properties
-rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
standalone/configuration/logging.properties

However, I don't see the value of letting those files accessible either
group member or any user on the system, but maybe we can make the argument
they should. But the write privileges for group member sounds wrong to me.

Also, I'm puzzled Brian and I are seeing different things - am I looking at
the correct zipfile here ?

Note: You also mention the module.xml - as far as I can see from the diff
provided with issue JBEAP-12374, I don't see any issue with privileges
regarding those files, so we can remove them of the discussion. The only
changes we need to discuss is removing the 'write' privileges' for the
group on jars, reducing the scope of permissions on (some) folders, and
privileges on (some) properties files. So, module.xml are out of the scope.

On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> Seems I forgot to "Reply to All" yesterday. The following was meant to be
> sent to wildfly-dev.
>
> On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>> Before getting into the specifics, first a general note re: perms.
>>
>> Our general permission set for is rwxr-xr-x for directories and rwxr--r--
>> for files. If someone thinks that's wrong in general; speak up. ;).
>> Otherwise I think any deviation from that we should justify. Not that
>> deviations are wrong, just that they need to have a reason.
>>
>> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <belaran at redhat.com>
>> wrote:
>>
>>> Well, the diff is between the RPM and the zipfile is pretty long, but it
>>> boils down to the 3 set of differences I've pointed out on WFLY-9574:
>>> <https://issues.jboss.org/browse/WFLY-9574>
>>>
>>>    - *.properties and .jar* files are associated with the mask
>>>    rw-rw-r-- giving access to it to any other users and allowing group member
>>>    to modify the file - the RPM distribution fixes that by removing the write
>>>    privileges for the group (rw-r--r--). I personnaly don't see the value of
>>>    letting the group members modify those files, I just can see how this could
>>>    be exploited, so I would say it falls into "clearly wrong and not our
>>>    intent". A case might be made for the .properties files, but for jars file
>>>    I really don't see a valid use case (unless of course, any of you know one)
>>>    ;
>>>
>>> There are a few different things here, so let's deal with them
>> separately.
>>
>> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as
>> rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I
>> don't see why they should vary from the general standard. And the
>> module.xml file should be consistent, since there's not much point in
>> locking people from touching jars but letting them change what jars get
>> loaded.
>>
>> For properties files, let's consider them on a more fine-grained basis.
>> For example, the properties files used by the security realms have
>> different kinds of data than logging.properties does.
>>
>> The perms on the security realm property files are rw-------, not
>> rw-rw-r--.
>>
>> The logging.properties files are rw-r--r-- which is consistent with the
>> domain|host|standalone.xml files and with the general standard.
>>
>>
>>>
>>>    -
>>>    - *some directories* like 'domain/tmp/auth' have too restrictive
>>>    mask like rwx------ and RPMS to turned them into rwxrwxr-x (that I don't
>>>    really agree with) and
>>>
>>>
>>>    - *other directories*, likes 'domain' have again a too permissive
>>>    mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make senses.
>>>
>>> In the unzip I see these directories as rwxr-xr-x, which I think is fine.
>>
>> Are you concerned with any other directories besides $JBOSS_HOME/domain
>> and $JBOSS_HOME/standalone?
>>
>>> So we need to find an agreement on those three items, and then see how
>>> we proceed to implement the fix (if needed).
>>>
>>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry <
>>> brian.stansberry at redhat.com> wrote:
>>>
>>>> I think we need to start with the assumption that the permissions we
>>>> have in the zip are the way they are for a reason and evaluate possible
>>>> changes based on discussion here of each type of change. Maybe the RPM
>>>> settings are better, maybe they are not. Or maybe they are better but the
>>>> improvement is not worth the disruption a change may cause to our end
>>>> users, who may rely on the current zip settings. Or maybe what we have in
>>>> the zip is clearly wrong and doesn't follow our own intent. I expect we'll
>>>> probably see a little of each category, although hopefully some changes for
>>>> WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :)
>>>>
>>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <belaran at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> As reported on JBEAP-12374[1], there is some discrepancies between the
>>>>> ZIP file we provided for Widlfy/EAP and the RPM generate. Most of those
>>>>> discrepancies - or the most relevant ones, are some fine tuning performed
>>>>> on the (POSIX) privileges (things such as removing the write privilege for
>>>>> member of the same group as the owner of the file).
>>>>>
>>>>> I've looked into this and because those files are produced by our own
>>>>> Maven plugin (as part of wildfly-build-tools), we can not simply modify the
>>>>> assembly.xml. Which actually is probably for the best, as it would made the
>>>>> assembly file quite cumbersome.
>>>>>
>>>>> Anyhow, I've worked on a proposal[2] for the wildfly-build-tools, but
>>>>> when I reported the problem on WFLY-9574[3], Brian suggested I started a
>>>>> discussion here. So does anyone have a (strong) opinion about this issue
>>>>> and/or how to resolve it ? :)
>>>>>
>>>>> (For the record, I do think it is best to fix the privileges to follow
>>>>> what the RPM does for us for now, but if you feel this issue should not be
>>>>> addressed, and dev- the issue, I'm certainly not opposed to it either).
>>>>>
>>>>> [1] https://issues.jboss.org/browse/JBEAP-12374
>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40
>>>>> [3] https://issues.jboss.org/browse/WFLY-9574
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Manager, Senior Principal Software Engineer
>>>> Red Hat
>>>>
>>>
>>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>>
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171201/b1bdc40b/attachment-0001.html 

From david.lloyd at redhat.com  Fri Dec  1 09:30:12 2017
From: david.lloyd at redhat.com (David Lloyd)
Date: Fri, 1 Dec 2017 08:30:12 -0600
Subject: [wildfly-dev] Policies for merging PRs on master
In-Reply-To: <CAKQecn95fhbz4w7SMBoc+QvSCbcyJ=7MsK_2V3QOqU-2Ja5xrQ@mail.gmail.com>
References: <CAKQecn95fhbz4w7SMBoc+QvSCbcyJ=7MsK_2V3QOqU-2Ja5xrQ@mail.gmail.com>
Message-ID: <CANghgrRT+qD351=s0cNP24Rjz5ny9Ys8Axy3K-chbxQ8d+iPuw@mail.gmail.com>

On Thu, Nov 30, 2017 at 5:50 PM, Alessio Soldano <asoldano at redhat.com> wrote:
> As suggested by Brian, I'd like to draw attention to the discussion on
> https://github.com/wildfly/wildfly/pull/10604 .
> The PR is an upgrade of the webservices stack, including JBossWS, Apache
> CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade is for EE8 and
> better JDK 9 compatibility.
> Now, due to the upgrade of the JAXB API spec jar, the PR is essentially
> stalled since 20 days; the new spec is released as an alpha (as it's been
> tested within JBossWS only) and that does not satisfy a rule that requires
> any artifact being pulled to be Final.
> We're talking about a spec jar, we could simply re-tag that as Final,
> chances are we won't need changes any time soon there anyway, but as Tomaz
> pointed out, in principle that would be dishonest.

My opinion is that you should go ahead and make a .Final tag.  In the
(unlikely?) event that the spec has to be modified for some reason, I
think you could make a 1.0.1.Final tag and call it a "bug fix".

The alternative is to simply wait.  I don't think there is any middle position.

> While I see the point in requiring that only sufficiently stable upgrades
> are applied to the codebase, I'm wondering whether, maybe, we're going a bit
> too far with the rules. Brian wrote on this topic: "how to determine that
> something is good enough to go in without using master as a test bed" ?

I don't think we are; I agree with the policy as it stands.  If you
look at it in terms of being able to release at any time, then it
follows that everything _must_ be stable.

-- 
- DML

From david.lloyd at redhat.com  Fri Dec  1 10:23:34 2017
From: david.lloyd at redhat.com (David Lloyd)
Date: Fri, 1 Dec 2017 09:23:34 -0600
Subject: [wildfly-dev] Moving JBoss Modules towards Java 9 integration
Message-ID: <CANghgrSpth9XKjsEewzUoFvC9c8Z=Ow7GCJ0a6F=KNE+TMekiw@mail.gmail.com>

Hi everyone, I want to outline a brief plan for the next couple steps
towards a better alignment between JBoss Modules and Java 9.

In Java 9, the platform classes are divided up into modules; the core set being:

java.base        java.compiler      java.datatransfer
java.desktop     java.instrument    java.jnlp
java.logging     java.management    java.management.rmi
java.naming      java.prefs         java.rmi
java.scripting   java.security.jgss java.security.sasl
java.smartcardio java.sql           java.sql.rowset
java.xml         java.xml.crypto

In addition, the java.se module re-exports many of these.

As a first step towards alignment, it seems to me that we need to
introduce the ability for modules to create module dependencies on
these module names.  However, unless we want to require Java 9 from
now on, the names must also work on Java 8.

So, I plan to follow this approximate plan:

? Introduce a new PlatformModuleLoader in to JBoss Modules JDK-specific code
    ? On Java 9+, this loader will create modules from the
corresponding JPMS platform module set
    ? On Java 8, this loader will create "system" modules from the
path sets which comprise the contents of these modules, possibly
including some "jdk.*" modules which are equivalent between Java 8 and
Java 9
? Update the LocalModuleLoader to pre-delegate module searches to
PlatformModuleLoader
? Remove "java" from the "system packages list"
? Bring these changes in to WildFly Core
? Deprecate the "javax.api", "sun.jdk", etc. modules, and also APIs
which use a different-than-standard name like "javax.sql.api", replace
their system dependency content with regular re-export dependencies on
platform modules
? Deprecate and replace other modules whose names are standardized but
different than ours, such as "java.corba", "java.transaction",
"java.xml.bind", etc., with delegations to modules with the standard
name
? Remove the "system" dependency type from the "urn:jboss:module:1.7" schema

One of the remaining unknowns is that there is only one Java 9
platform family in the wild right now, and it's OpenJDK-based.  Other
vendors might introduce a different set of "jdk.*" modules, for
example, which might mean that the Java 8 emulation code for that
platform family may have to be updated.  I consider this risk to be
mitigable.

It may also be necessary to have a compatibility mode or flag to
automatically add "java.se" as a module dependency, or perhaps to
re-add the "java" package prefix to the system package set, depending
on how compatibility shapes up in the end.

I hope to achieve this work in JBoss Modules 1.7; this would probably
be the last significant change before I start moving towards .Final.
So, if you have any feedback on this idea, please let me know here
ASAP.  Thanks!

-- 
- DML


From asoldano at redhat.com  Fri Dec  1 11:04:31 2017
From: asoldano at redhat.com (Alessio Soldano)
Date: Fri, 1 Dec 2017 17:04:31 +0100
Subject: [wildfly-dev] Policies for merging PRs on master
In-Reply-To: <CANghgrRT+qD351=s0cNP24Rjz5ny9Ys8Axy3K-chbxQ8d+iPuw@mail.gmail.com>
References: <CAKQecn95fhbz4w7SMBoc+QvSCbcyJ=7MsK_2V3QOqU-2Ja5xrQ@mail.gmail.com>
	<CANghgrRT+qD351=s0cNP24Rjz5ny9Ys8Axy3K-chbxQ8d+iPuw@mail.gmail.com>
Message-ID: <CAKQecn-UrxaYG=Q-ELYLqDti0vcRzY-LwYCicbV600xqnUuULg@mail.gmail.com>

There you go... PR updated to consume the same api jar now released as
final.

Cheers
Alessio

On Fri, Dec 1, 2017 at 3:30 PM, David Lloyd <david.lloyd at redhat.com> wrote:

> On Thu, Nov 30, 2017 at 5:50 PM, Alessio Soldano <asoldano at redhat.com>
> wrote:
> > As suggested by Brian, I'd like to draw attention to the discussion on
> > https://github.com/wildfly/wildfly/pull/10604 .
> > The PR is an upgrade of the webservices stack, including JBossWS, Apache
> > CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade is for EE8 and
> > better JDK 9 compatibility.
> > Now, due to the upgrade of the JAXB API spec jar, the PR is essentially
> > stalled since 20 days; the new spec is released as an alpha (as it's been
> > tested within JBossWS only) and that does not satisfy a rule that
> requires
> > any artifact being pulled to be Final.
> > We're talking about a spec jar, we could simply re-tag that as Final,
> > chances are we won't need changes any time soon there anyway, but as
> Tomaz
> > pointed out, in principle that would be dishonest.
>
> My opinion is that you should go ahead and make a .Final tag.  In the
> (unlikely?) event that the spec has to be modified for some reason, I
> think you could make a 1.0.1.Final tag and call it a "bug fix".
>
> The alternative is to simply wait.  I don't think there is any middle
> position.
>
> > While I see the point in requiring that only sufficiently stable upgrades
> > are applied to the codebase, I'm wondering whether, maybe, we're going a
> bit
> > too far with the rules. Brian wrote on this topic: "how to determine that
> > something is good enough to go in without using master as a test bed" ?
>
> I don't think we are; I agree with the policy as it stands.  If you
> look at it in terms of being able to release at any time, then it
> follows that everything _must_ be stable.
>
> --
> - DML
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171201/04a807aa/attachment.html 

From anmiller at redhat.com  Fri Dec  1 13:12:59 2017
From: anmiller at redhat.com (Andrig Miller)
Date: Fri, 1 Dec 2017 11:12:59 -0700
Subject: [wildfly-dev] Moving JBoss Modules towards Java 9 integration
In-Reply-To: <CANghgrSpth9XKjsEewzUoFvC9c8Z=Ow7GCJ0a6F=KNE+TMekiw@mail.gmail.com>
References: <CANghgrSpth9XKjsEewzUoFvC9c8Z=Ow7GCJ0a6F=KNE+TMekiw@mail.gmail.com>
Message-ID: <CAF1-sp6KgSwPd0s52zsRL7TPxHwY5Aj4L7x-_nTakGpwH4UjxQ@mail.gmail.com>

One thing we need to measure, as we move towards full Java 9 support, is
what the impact is on MetaSpace.  In theory, having the JDK modularized
could improve our MetaSpace usage, but I'm not sure.  Certainly, we don't
want it to get worse.

Andy

On Fri, Dec 1, 2017 at 8:23 AM, David Lloyd <david.lloyd at redhat.com> wrote:

> Hi everyone, I want to outline a brief plan for the next couple steps
> towards a better alignment between JBoss Modules and Java 9.
>
> In Java 9, the platform classes are divided up into modules; the core set
> being:
>
> java.base        java.compiler      java.datatransfer
> java.desktop     java.instrument    java.jnlp
> java.logging     java.management    java.management.rmi
> java.naming      java.prefs         java.rmi
> java.scripting   java.security.jgss java.security.sasl
> java.smartcardio java.sql           java.sql.rowset
> java.xml         java.xml.crypto
>
> In addition, the java.se module re-exports many of these.
>
> As a first step towards alignment, it seems to me that we need to
> introduce the ability for modules to create module dependencies on
> these module names.  However, unless we want to require Java 9 from
> now on, the names must also work on Java 8.
>
> So, I plan to follow this approximate plan:
>
> ? Introduce a new PlatformModuleLoader in to JBoss Modules JDK-specific
> code
>     ? On Java 9+, this loader will create modules from the
> corresponding JPMS platform module set
>     ? On Java 8, this loader will create "system" modules from the
> path sets which comprise the contents of these modules, possibly
> including some "jdk.*" modules which are equivalent between Java 8 and
> Java 9
> ? Update the LocalModuleLoader to pre-delegate module searches to
> PlatformModuleLoader
> ? Remove "java" from the "system packages list"
> ? Bring these changes in to WildFly Core
> ? Deprecate the "javax.api", "sun.jdk", etc. modules, and also APIs
> which use a different-than-standard name like "javax.sql.api", replace
> their system dependency content with regular re-export dependencies on
> platform modules
> ? Deprecate and replace other modules whose names are standardized but
> different than ours, such as "java.corba", "java.transaction",
> "java.xml.bind", etc., with delegations to modules with the standard
> name
> ? Remove the "system" dependency type from the "urn:jboss:module:1.7"
> schema
>
> One of the remaining unknowns is that there is only one Java 9
> platform family in the wild right now, and it's OpenJDK-based.  Other
> vendors might introduce a different set of "jdk.*" modules, for
> example, which might mean that the Java 8 emulation code for that
> platform family may have to be updated.  I consider this risk to be
> mitigable.
>
> It may also be necessary to have a compatibility mode or flag to
> automatically add "java.se" as a module dependency, or perhaps to
> re-add the "java" package prefix to the system package set, depending
> on how compatibility shapes up in the end.
>
> I hope to achieve this work in JBoss Modules 1.7; this would probably
> be the last significant change before I start moving towards .Final.
> So, if you have any feedback on this idea, please let me know here
> ASAP.  Thanks!
>
> --
> - DML
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev




-- 
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171201/139d0331/attachment.html 

From ropalka at redhat.com  Mon Dec  4 05:26:45 2017
From: ropalka at redhat.com (Richard Opalka)
Date: Mon, 4 Dec 2017 11:26:45 +0100
Subject: [wildfly-dev] Moving JBoss Modules towards Java 9 integration
In-Reply-To: <CANghgrSpth9XKjsEewzUoFvC9c8Z=Ow7GCJ0a6F=KNE+TMekiw@mail.gmail.com>
References: <CANghgrSpth9XKjsEewzUoFvC9c8Z=Ow7GCJ0a6F=KNE+TMekiw@mail.gmail.com>
Message-ID: <CABSyOEFGjao9xntUMm=21sJ1Dcx04Yij-gtBdyhGBRUS2zovAg@mail.gmail.com>

Hi David,

   comments inlined ...

On Fri, Dec 1, 2017 at 4:23 PM, David Lloyd <david.lloyd at redhat.com> wrote:

> Hi everyone, I want to outline a brief plan for the next couple steps
> towards a better alignment between JBoss Modules and Java 9.
>
> In Java 9, the platform classes are divided up into modules; the core set
> being:
>
> java.base        java.compiler      java.datatransfer
> java.desktop     java.instrument    java.jnlp
> java.logging     java.management    java.management.rmi
> java.naming      java.prefs         java.rmi
> java.scripting   java.security.jgss java.security.sasl
> java.smartcardio java.sql           java.sql.rowset
> java.xml         java.xml.crypto
>
> In addition, the java.se module re-exports many of these.
>
> As a first step towards alignment, it seems to me that we need to
> introduce the ability for modules to create module dependencies on
> these module names.  However, unless we want to require Java 9 from
> now on, the names must also work on Java 8.
>
> So, I plan to follow this approximate plan:
>
> ? Introduce a new PlatformModuleLoader in to JBoss Modules JDK-specific
> code
>     ? On Java 9+, this loader will create modules from the
> corresponding JPMS platform module set
>     ? On Java 8, this loader will create "system" modules from the
> path sets which comprise the contents of these modules, possibly
> including some "jdk.*" modules which are equivalent between Java 8 and
> Java 9
> ? Update the LocalModuleLoader to pre-delegate module searches to
> PlatformModuleLoader
> ? Remove "java" from the "system packages list"
> ? Bring these changes in to WildFly Core
> ? Deprecate the "javax.api", "sun.jdk", etc. modules, and also APIs
> which use a different-than-standard name like "javax.sql.api", replace
> their system dependency content with regular re-export dependencies on
> platform modules
>

I guess you meant introduction of "deprecated" attribute / element in
"urn:jboss:module:1.7" schema for module and module-alias elements?
I'd say <deprecated/> element would be better fit here because we
could specify the following optional attributes on it:
 * "forRemoval" = "true" // Indicates whether the module or module alias is
subject to removal in a future version
 * "since" = "12.0" // The version in which the annotated module or module
alias became deprecated
 * finally <deprecated/> element might contain text describing reason why
module or module alias have been deprecated

Elaborating this idea further JBoss-Modules library should print warnings
to the console if
deprecated module or module-alias is loaded.

? Deprecate and replace other modules whose names are standardized but
> different than ours, such as "java.corba", "java.transaction",
> "java.xml.bind", etc., with delegations to modules with the standard
> name
>

Deprecated modules might become alias modules of newly introduced modules.


> ? Remove the "system" dependency type from the "urn:jboss:module:1.7"
> schema
>
> One of the remaining unknowns is that there is only one Java 9
> platform family in the wild right now, and it's OpenJDK-based.  Other
> vendors might introduce a different set of "jdk.*" modules, for
> example, which might mean that the Java 8 emulation code for that
> platform family may have to be updated.  I consider this risk to be
> mitigable.
>

I'd say it's very unlikely but yes, it's still a possibility.

>
> It may also be necessary to have a compatibility mode or flag to
> automatically add "java.se" as a module dependency, or perhaps to
> re-add the "java" package prefix to the system package set, depending
> on how compatibility shapes up in the end.
>

Hopefully it will not be necessary.

>
> I hope to achieve this work in JBoss Modules 1.7; this would probably
> be the last significant change before I start moving towards .Final.
> So, if you have any feedback on this idea, please let me know here
> ASAP.  Thanks!
>

Overall it's very reasonable proposal.

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


Rio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171204/1a6655af/attachment-0001.html 

From brian.stansberry at redhat.com  Mon Dec  4 11:40:24 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 4 Dec 2017 10:40:24 -0600
Subject: [wildfly-dev] Policies for merging PRs on master
In-Reply-To: <CAKQecn-UrxaYG=Q-ELYLqDti0vcRzY-LwYCicbV600xqnUuULg@mail.gmail.com>
References: <CAKQecn95fhbz4w7SMBoc+QvSCbcyJ=7MsK_2V3QOqU-2Ja5xrQ@mail.gmail.com>
	<CANghgrRT+qD351=s0cNP24Rjz5ny9Ys8Axy3K-chbxQ8d+iPuw@mail.gmail.com>
	<CAKQecn-UrxaYG=Q-ELYLqDti0vcRzY-LwYCicbV600xqnUuULg@mail.gmail.com>
Message-ID: <CAPhbRDY7rsynXLy1HR0+Cg5JLS_+CVBx3G+4QNuWXpW6aW2BfA@mail.gmail.com>

Great. :)

One thing I think we need to do is figure out how to get custom TCK runs
for PR branches. The TCK is a big part of our test coverage, and one way to
not "use master as a test bed" is to get a check of a branch on the TCK
before we merge it.

I know we've gotten TCK runs of ad-hoc branches before, so by "figure out"
I mean work out how to make that not overly painful, come to some sort of
consensus on when it's worthwhile, etc.

On Fri, Dec 1, 2017 at 10:04 AM, Alessio Soldano <asoldano at redhat.com>
wrote:

> There you go... PR updated to consume the same api jar now released as
> final.
>
> Cheers
> Alessio
>
> On Fri, Dec 1, 2017 at 3:30 PM, David Lloyd <david.lloyd at redhat.com>
> wrote:
>
>> On Thu, Nov 30, 2017 at 5:50 PM, Alessio Soldano <asoldano at redhat.com>
>> wrote:
>> > As suggested by Brian, I'd like to draw attention to the discussion on
>> > https://github.com/wildfly/wildfly/pull/10604 .
>> > The PR is an upgrade of the webservices stack, including JBossWS, Apache
>> > CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade is for EE8
>> and
>> > better JDK 9 compatibility.
>> > Now, due to the upgrade of the JAXB API spec jar, the PR is essentially
>> > stalled since 20 days; the new spec is released as an alpha (as it's
>> been
>> > tested within JBossWS only) and that does not satisfy a rule that
>> requires
>> > any artifact being pulled to be Final.
>> > We're talking about a spec jar, we could simply re-tag that as Final,
>> > chances are we won't need changes any time soon there anyway, but as
>> Tomaz
>> > pointed out, in principle that would be dishonest.
>>
>> My opinion is that you should go ahead and make a .Final tag.  In the
>> (unlikely?) event that the spec has to be modified for some reason, I
>> think you could make a 1.0.1.Final tag and call it a "bug fix".
>>
>> The alternative is to simply wait.  I don't think there is any middle
>> position.
>>
>> > While I see the point in requiring that only sufficiently stable
>> upgrades
>> > are applied to the codebase, I'm wondering whether, maybe, we're going
>> a bit
>> > too far with the rules. Brian wrote on this topic: "how to determine
>> that
>> > something is good enough to go in without using master as a test bed" ?
>>
>> I don't think we are; I agree with the policy as it stands.  If you
>> look at it in terms of being able to release at any time, then it
>> follows that everything _must_ be stable.
>>
>> --
>> - DML
>>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171204/784242ba/attachment.html 

From brian.stansberry at redhat.com  Mon Dec  4 12:38:09 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 4 Dec 2017 11:38:09 -0600
Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have
 POSIX permissions perfectly set
In-Reply-To: <CALuBA_pXT89PNspojT-sT3GNTVhf1R1F7YJPxn7K-B6dmP4+bg@mail.gmail.com>
References: <CALuBA_p5Mqag2+TSD9bUWGM5BgDpirdZC7zvL5OE8w-HfA4AWw@mail.gmail.com>
	<CAPhbRDYyGwNpqFq8bYdRk53_hx6Mg4yHwOcmmYYnwDp_3-B+_A@mail.gmail.com>
	<CALuBA_pSvfNYPug1byQrS7Bic45vVvvdQ4Mjd-BQ6Pa4t5m05g@mail.gmail.com>
	<CAPhbRDYnYLd-SXuE_m_2b14W9VwNhy08KDpC0MdP6n3mipMi0A@mail.gmail.com>
	<CAPhbRDZFTd52gO8-psaaXJSVNAPn=3MtjA3XuyEC501Hj-rRJw@mail.gmail.com>
	<CALuBA_pXT89PNspojT-sT3GNTVhf1R1F7YJPxn7K-B6dmP4+bg@mail.gmail.com>
Message-ID: <CAPhbRDZFfcuS5kZNHU99cVDSTjewsVynuaZAAxsxdQSswxOZOA@mail.gmail.com>

Thanks, Romain.

Re: what the actual permissions are, FWIW I get what I see on both my
macbook and my Fedora 27 machine, both when unzipping the actual
11.0.0.Final and when unzipping the result of a build of master, and both
with and without the -Prelease -Pjboss-release args to maven that we
include when doing actual releases. Unzipping the zip in build/target
doesn't include the jars of course.

So it sounds like we need input from others.

Re: modules.xml, if you are seeing those as rw-r--r-- as well, then +1 to
ignoring them in further discussion.

Re: logging.properties, those serve a very similar conceptual role to the
standalone|host|domain.xml files so I see no reason for them to have
different perms. However, you and I are getting different results, where
you report them as group writable and I don't. What do you see for the xml
config files?

Re: RPM changing to match WildFly, that's an EAP discussion, so that can be
taken up elsewhere once we have WildFly the way we want it.


On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse <belaran at redhat.com> wrote:

> Hi Brian and all,
>
> err, my own observation differs from yours. I've rebuild Wildfly from the
> last content of the master branch and get the same privileges on the
> jboss-modules.jar (so -rw-rw-r-- and not as you are seeing  rwxr--r--).
> Same with the domain folder, which turns out on my local system associated
> to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a
> transcript of what I did - maybe you can spot why our results differs so
> much.
>
> $ git show
> commit 46e119c65d9e32bc0ec69f3933267fece959ed3f
> Merge: 051f080 c7d9075
> Author: Kabir Khan <kkhan at redhat.com>
> Date:   Tue Nov 28 17:46:40 2017 +0000
>
>     Merge pull request #10669 from praxeo/WFLY-9284
>
>     WFLY-9284 Correct MVN env variable to mvnw.cmd
>
> $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d
> wildfly-12.zip
> ...
> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
> -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov.  11:41
> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/  -d
> drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov.  11:41
> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/
>
> Checking all the jars in the distribution, they all appears to have the
> mask '-rw-rw-r--':
>
> $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done | sed -e
> '/-rw-rw-r--/d'
> $
>
> Regarding properties files, here is the exhaustive list of properties that
> RPM packaging has modified the privileges of:
>
> appclient/configuration/logging.properties rw-------
> domain/configuration/application-roles.properties rw-------
> domain/configuration/default-server-logging.properties rw-------
> domain/configuration/logging.properties rw-------
> domain/configuration/mgmt-groups.properties rw-------
> standalone/configuration/application-roles.properties rw-------
> standalone/configuration/logging.properties rw-------
> standalone/configuration/mgmt-groups.properties rw-------
>
> If I compare that with the content of the extract zip (same fresh built as
> above), I can see that 4 files are not having the same mask (rw------):
>
> $ for file in $(cut -f1 -d\  ../../../list-props-files.txt ); do ls -l
> $file ; done
> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
> appclient/configuration/logging.properties
> -rw-------. 1 rpelisse rpelisse 710 30 nov.  11:41 domain/configuration/
> application-roles.properties
> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
> domain/configuration/default-server-logging.properties
> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
> domain/configuration/logging.properties
> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
> domain/configuration/mgmt-groups.properties
> -rw-------. 1 rpelisse rpelisse 711 30 nov.  11:41
> standalone/configuration/application-roles.properties
> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
> standalone/configuration/logging.properties
> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
> standalone/configuration/mgmt-groups.properties
>
> Now, as you said, those files privileges are indeed fine-grained, so maybe
> we can push back to people making the RPM for them to NOT change the
> following files privileges:
>
> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
> appclient/configuration/logging.properties
> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
> domain/configuration/default-server-logging.properties
> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
> domain/configuration/logging.properties
> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
> standalone/configuration/logging.properties
>
> However, I don't see the value of letting those files accessible either
> group member or any user on the system, but maybe we can make the argument
> they should. But the write privileges for group member sounds wrong to me.
>
> Also, I'm puzzled Brian and I are seeing different things - am I looking
> at the correct zipfile here ?
>
> Note: You also mention the module.xml - as far as I can see from the diff
> provided with issue JBEAP-12374, I don't see any issue with privileges
> regarding those files, so we can remove them of the discussion. The only
> changes we need to discuss is removing the 'write' privileges' for the
> group on jars, reducing the scope of permissions on (some) folders, and
> privileges on (some) properties files. So, module.xml are out of the scope.
>
> On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>> Seems I forgot to "Reply to All" yesterday. The following was meant to be
>> sent to wildfly-dev.
>>
>> On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>>
>>> Before getting into the specifics, first a general note re: perms.
>>>
>>> Our general permission set for is rwxr-xr-x for directories and
>>> rwxr--r-- for files. If someone thinks that's wrong in general; speak up.
>>> ;). Otherwise I think any deviation from that we should justify. Not that
>>> deviations are wrong, just that they need to have a reason.
>>>
>>> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <belaran at redhat.com>
>>> wrote:
>>>
>>>> Well, the diff is between the RPM and the zipfile is pretty long, but
>>>> it boils down to the 3 set of differences I've pointed out on
>>>> WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574>
>>>>
>>>>    - *.properties and .jar* files are associated with the mask
>>>>    rw-rw-r-- giving access to it to any other users and allowing group member
>>>>    to modify the file - the RPM distribution fixes that by removing the write
>>>>    privileges for the group (rw-r--r--). I personnaly don't see the value of
>>>>    letting the group members modify those files, I just can see how this could
>>>>    be exploited, so I would say it falls into "clearly wrong and not our
>>>>    intent". A case might be made for the .properties files, but for jars file
>>>>    I really don't see a valid use case (unless of course, any of you know one)
>>>>    ;
>>>>
>>>> There are a few different things here, so let's deal with them
>>> separately.
>>>
>>> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as
>>> rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I
>>> don't see why they should vary from the general standard. And the
>>> module.xml file should be consistent, since there's not much point in
>>> locking people from touching jars but letting them change what jars get
>>> loaded.
>>>
>>> For properties files, let's consider them on a more fine-grained basis.
>>> For example, the properties files used by the security realms have
>>> different kinds of data than logging.properties does.
>>>
>>> The perms on the security realm property files are rw-------, not
>>> rw-rw-r--.
>>>
>>> The logging.properties files are rw-r--r-- which is consistent with the
>>> domain|host|standalone.xml files and with the general standard.
>>>
>>>
>>>>
>>>>    -
>>>>    - *some directories* like 'domain/tmp/auth' have too restrictive
>>>>    mask like rwx------ and RPMS to turned them into rwxrwxr-x (that I don't
>>>>    really agree with) and
>>>>
>>>>
>>>>    - *other directories*, likes 'domain' have again a too permissive
>>>>    mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make senses.
>>>>
>>>> In the unzip I see these directories as rwxr-xr-x, which I think is
>>> fine.
>>>
>>> Are you concerned with any other directories besides $JBOSS_HOME/domain
>>> and $JBOSS_HOME/standalone?
>>>
>>>> So we need to find an agreement on those three items, and then see how
>>>> we proceed to implement the fix (if needed).
>>>>
>>>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry <
>>>> brian.stansberry at redhat.com> wrote:
>>>>
>>>>> I think we need to start with the assumption that the permissions we
>>>>> have in the zip are the way they are for a reason and evaluate possible
>>>>> changes based on discussion here of each type of change. Maybe the RPM
>>>>> settings are better, maybe they are not. Or maybe they are better but the
>>>>> improvement is not worth the disruption a change may cause to our end
>>>>> users, who may rely on the current zip settings. Or maybe what we have in
>>>>> the zip is clearly wrong and doesn't follow our own intent. I expect we'll
>>>>> probably see a little of each category, although hopefully some changes for
>>>>> WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :)
>>>>>
>>>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <belaran at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> As reported on JBEAP-12374[1], there is some discrepancies between
>>>>>> the ZIP file we provided for Widlfy/EAP and the RPM generate. Most of those
>>>>>> discrepancies - or the most relevant ones, are some fine tuning performed
>>>>>> on the (POSIX) privileges (things such as removing the write privilege for
>>>>>> member of the same group as the owner of the file).
>>>>>>
>>>>>> I've looked into this and because those files are produced by our own
>>>>>> Maven plugin (as part of wildfly-build-tools), we can not simply modify the
>>>>>> assembly.xml. Which actually is probably for the best, as it would made the
>>>>>> assembly file quite cumbersome.
>>>>>>
>>>>>> Anyhow, I've worked on a proposal[2] for the wildfly-build-tools, but
>>>>>> when I reported the problem on WFLY-9574[3], Brian suggested I started a
>>>>>> discussion here. So does anyone have a (strong) opinion about this issue
>>>>>> and/or how to resolve it ? :)
>>>>>>
>>>>>> (For the record, I do think it is best to fix the privileges to
>>>>>> follow what the RPM does for us for now, but if you feel this issue should
>>>>>> not be addressed, and dev- the issue, I'm certainly not opposed to it
>>>>>> either).
>>>>>>
>>>>>> [1] https://issues.jboss.org/browse/JBEAP-12374
>>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40
>>>>>> [3] https://issues.jboss.org/browse/WFLY-9574
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Manager, Senior Principal Software Engineer
>>>>> Red Hat
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> Red Hat
>>>
>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>>
>
>


-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171204/59166224/attachment-0001.html 

From brian.stansberry at redhat.com  Mon Dec  4 12:48:41 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 4 Dec 2017 11:48:41 -0600
Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have
 POSIX permissions perfectly set
In-Reply-To: <CAPhbRDZFfcuS5kZNHU99cVDSTjewsVynuaZAAxsxdQSswxOZOA@mail.gmail.com>
References: <CALuBA_p5Mqag2+TSD9bUWGM5BgDpirdZC7zvL5OE8w-HfA4AWw@mail.gmail.com>
	<CAPhbRDYyGwNpqFq8bYdRk53_hx6Mg4yHwOcmmYYnwDp_3-B+_A@mail.gmail.com>
	<CALuBA_pSvfNYPug1byQrS7Bic45vVvvdQ4Mjd-BQ6Pa4t5m05g@mail.gmail.com>
	<CAPhbRDYnYLd-SXuE_m_2b14W9VwNhy08KDpC0MdP6n3mipMi0A@mail.gmail.com>
	<CAPhbRDZFTd52gO8-psaaXJSVNAPn=3MtjA3XuyEC501Hj-rRJw@mail.gmail.com>
	<CALuBA_pXT89PNspojT-sT3GNTVhf1R1F7YJPxn7K-B6dmP4+bg@mail.gmail.com>
	<CAPhbRDZFfcuS5kZNHU99cVDSTjewsVynuaZAAxsxdQSswxOZOA@mail.gmail.com>
Message-ID: <CAPhbRDYN_PGP8fo6BizQ3EOR-=9UT_jrJEECzLBfT-DoOt05fg@mail.gmail.com>

A slightly different topic, related to the "logging.properties/xml config
file" topic is whether these files should be world and/or group readable.

Changing this has been proposed in the past on the EAP side, primarily
based on the argument that users could put sensitive data in these files.
This thread seems like a good time to debate this a bit in community.

I've resisted that primarily on the basis of:

1) These files or those similarly used have had these perms as far back as
I can find in JBoss AS. So the odds that some people are relying upon those
perms is fairly high and we need to assume a change would be a breaking
change for some people.

2) Other software I've looked at like Tomcat and httpd have similar
permission schemes to what we have for their config files, which can also
potentially include sensitive data.

3) We provide facilities like the vault or elytron credential store refs
for keeping sensitive data out of the config files.


On Mon, Dec 4, 2017 at 11:38 AM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> Thanks, Romain.
>
> Re: what the actual permissions are, FWIW I get what I see on both my
> macbook and my Fedora 27 machine, both when unzipping the actual
> 11.0.0.Final and when unzipping the result of a build of master, and both
> with and without the -Prelease -Pjboss-release args to maven that we
> include when doing actual releases. Unzipping the zip in build/target
> doesn't include the jars of course.
>
> So it sounds like we need input from others.
>
> Re: modules.xml, if you are seeing those as rw-r--r-- as well, then +1 to
> ignoring them in further discussion.
>
> Re: logging.properties, those serve a very similar conceptual role to the
> standalone|host|domain.xml files so I see no reason for them to have
> different perms. However, you and I are getting different results, where
> you report them as group writable and I don't. What do you see for the xml
> config files?
>
> Re: RPM changing to match WildFly, that's an EAP discussion, so that can
> be taken up elsewhere once we have WildFly the way we want it.
>
>
> On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse <belaran at redhat.com> wrote:
>
>> Hi Brian and all,
>>
>> err, my own observation differs from yours. I've rebuild Wildfly from the
>> last content of the master branch and get the same privileges on the
>> jboss-modules.jar (so -rw-rw-r-- and not as you are seeing  rwxr--r--).
>> Same with the domain folder, which turns out on my local system associated
>> to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a
>> transcript of what I did - maybe you can spot why our results differs so
>> much.
>>
>> $ git show
>> commit 46e119c65d9e32bc0ec69f3933267fece959ed3f
>> Merge: 051f080 c7d9075
>> Author: Kabir Khan <kkhan at redhat.com>
>> Date:   Tue Nov 28 17:46:40 2017 +0000
>>
>>     Merge pull request #10669 from praxeo/WFLY-9284
>>
>>     WFLY-9284 Correct MVN env variable to mvnw.cmd
>>
>> $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d
>> wildfly-12.zip
>> ...
>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
>> -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov.  11:41
>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/  -d
>> drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov.  11:41
>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/
>>
>> Checking all the jars in the distribution, they all appears to have the
>> mask '-rw-rw-r--':
>>
>> $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done | sed -e
>> '/-rw-rw-r--/d'
>> $
>>
>> Regarding properties files, here is the exhaustive list of properties
>> that RPM packaging has modified the privileges of:
>>
>> appclient/configuration/logging.properties rw-------
>> domain/configuration/application-roles.properties rw-------
>> domain/configuration/default-server-logging.properties rw-------
>> domain/configuration/logging.properties rw-------
>> domain/configuration/mgmt-groups.properties rw-------
>> standalone/configuration/application-roles.properties rw-------
>> standalone/configuration/logging.properties rw-------
>> standalone/configuration/mgmt-groups.properties rw-------
>>
>> If I compare that with the content of the extract zip (same fresh built
>> as above), I can see that 4 files are not having the same mask (rw------):
>>
>> $ for file in $(cut -f1 -d\  ../../../list-props-files.txt ); do ls -l
>> $file ; done
>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>> appclient/configuration/logging.properties
>> -rw-------. 1 rpelisse rpelisse 710 30 nov.  11:41
>> domain/configuration/application-roles.properties
>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>> domain/configuration/default-server-logging.properties
>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>> domain/configuration/logging.properties
>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>> domain/configuration/mgmt-groups.properties
>> -rw-------. 1 rpelisse rpelisse 711 30 nov.  11:41
>> standalone/configuration/application-roles.properties
>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>> standalone/configuration/logging.properties
>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>> standalone/configuration/mgmt-groups.properties
>>
>> Now, as you said, those files privileges are indeed fine-grained, so
>> maybe we can push back to people making the RPM for them to NOT change the
>> following files privileges:
>>
>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>> appclient/configuration/logging.properties
>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>> domain/configuration/default-server-logging.properties
>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>> domain/configuration/logging.properties
>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>> standalone/configuration/logging.properties
>>
>> However, I don't see the value of letting those files accessible either
>> group member or any user on the system, but maybe we can make the argument
>> they should. But the write privileges for group member sounds wrong to me.
>>
>> Also, I'm puzzled Brian and I are seeing different things - am I looking
>> at the correct zipfile here ?
>>
>> Note: You also mention the module.xml - as far as I can see from the diff
>> provided with issue JBEAP-12374, I don't see any issue with privileges
>> regarding those files, so we can remove them of the discussion. The only
>> changes we need to discuss is removing the 'write' privileges' for the
>> group on jars, reducing the scope of permissions on (some) folders, and
>> privileges on (some) properties files. So, module.xml are out of the scope.
>>
>> On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>>
>>> Seems I forgot to "Reply to All" yesterday. The following was meant to
>>> be sent to wildfly-dev.
>>>
>>> On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry <
>>> brian.stansberry at redhat.com> wrote:
>>>
>>>> Before getting into the specifics, first a general note re: perms.
>>>>
>>>> Our general permission set for is rwxr-xr-x for directories and
>>>> rwxr--r-- for files. If someone thinks that's wrong in general; speak up.
>>>> ;). Otherwise I think any deviation from that we should justify. Not that
>>>> deviations are wrong, just that they need to have a reason.
>>>>
>>>> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <belaran at redhat.com>
>>>> wrote:
>>>>
>>>>> Well, the diff is between the RPM and the zipfile is pretty long, but
>>>>> it boils down to the 3 set of differences I've pointed out on
>>>>> WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574>
>>>>>
>>>>>    - *.properties and .jar* files are associated with the mask
>>>>>    rw-rw-r-- giving access to it to any other users and allowing group member
>>>>>    to modify the file - the RPM distribution fixes that by removing the write
>>>>>    privileges for the group (rw-r--r--). I personnaly don't see the value of
>>>>>    letting the group members modify those files, I just can see how this could
>>>>>    be exploited, so I would say it falls into "clearly wrong and not our
>>>>>    intent". A case might be made for the .properties files, but for jars file
>>>>>    I really don't see a valid use case (unless of course, any of you know one)
>>>>>    ;
>>>>>
>>>>> There are a few different things here, so let's deal with them
>>>> separately.
>>>>
>>>> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as
>>>> rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I
>>>> don't see why they should vary from the general standard. And the
>>>> module.xml file should be consistent, since there's not much point in
>>>> locking people from touching jars but letting them change what jars get
>>>> loaded.
>>>>
>>>> For properties files, let's consider them on a more fine-grained basis.
>>>> For example, the properties files used by the security realms have
>>>> different kinds of data than logging.properties does.
>>>>
>>>> The perms on the security realm property files are rw-------, not
>>>> rw-rw-r--.
>>>>
>>>> The logging.properties files are rw-r--r-- which is consistent with the
>>>> domain|host|standalone.xml files and with the general standard.
>>>>
>>>>
>>>>>
>>>>>    -
>>>>>    - *some directories* like 'domain/tmp/auth' have too restrictive
>>>>>    mask like rwx------ and RPMS to turned them into rwxrwxr-x (that I don't
>>>>>    really agree with) and
>>>>>
>>>>>
>>>>>    - *other directories*, likes 'domain' have again a too permissive
>>>>>    mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make senses.
>>>>>
>>>>> In the unzip I see these directories as rwxr-xr-x, which I think is
>>>> fine.
>>>>
>>>> Are you concerned with any other directories besides $JBOSS_HOME/domain
>>>> and $JBOSS_HOME/standalone?
>>>>
>>>>> So we need to find an agreement on those three items, and then see how
>>>>> we proceed to implement the fix (if needed).
>>>>>
>>>>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry <
>>>>> brian.stansberry at redhat.com> wrote:
>>>>>
>>>>>> I think we need to start with the assumption that the permissions we
>>>>>> have in the zip are the way they are for a reason and evaluate possible
>>>>>> changes based on discussion here of each type of change. Maybe the RPM
>>>>>> settings are better, maybe they are not. Or maybe they are better but the
>>>>>> improvement is not worth the disruption a change may cause to our end
>>>>>> users, who may rely on the current zip settings. Or maybe what we have in
>>>>>> the zip is clearly wrong and doesn't follow our own intent. I expect we'll
>>>>>> probably see a little of each category, although hopefully some changes for
>>>>>> WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :)
>>>>>>
>>>>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <belaran at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> As reported on JBEAP-12374[1], there is some discrepancies between
>>>>>>> the ZIP file we provided for Widlfy/EAP and the RPM generate. Most of those
>>>>>>> discrepancies - or the most relevant ones, are some fine tuning performed
>>>>>>> on the (POSIX) privileges (things such as removing the write privilege for
>>>>>>> member of the same group as the owner of the file).
>>>>>>>
>>>>>>> I've looked into this and because those files are produced by our
>>>>>>> own Maven plugin (as part of wildfly-build-tools), we can not simply modify
>>>>>>> the assembly.xml. Which actually is probably for the best, as it would made
>>>>>>> the assembly file quite cumbersome.
>>>>>>>
>>>>>>> Anyhow, I've worked on a proposal[2] for the wildfly-build-tools,
>>>>>>> but when I reported the problem on WFLY-9574[3], Brian suggested I started
>>>>>>> a discussion here. So does anyone have a (strong) opinion about this issue
>>>>>>> and/or how to resolve it ? :)
>>>>>>>
>>>>>>> (For the record, I do think it is best to fix the privileges to
>>>>>>> follow what the RPM does for us for now, but if you feel this issue should
>>>>>>> not be addressed, and dev- the issue, I'm certainly not opposed to it
>>>>>>> either).
>>>>>>>
>>>>>>> [1] https://issues.jboss.org/browse/JBEAP-12374
>>>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40
>>>>>>> [3] https://issues.jboss.org/browse/WFLY-9574
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> wildfly-dev mailing list
>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Brian Stansberry
>>>>>> Manager, Senior Principal Software Engineer
>>>>>> Red Hat
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Manager, Senior Principal Software Engineer
>>>> Red Hat
>>>>
>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> Red Hat
>>>
>>
>>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171204/42c5dd5b/attachment-0001.html 

From stuart.w.douglas at gmail.com  Mon Dec  4 21:33:30 2017
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 5 Dec 2017 13:33:30 +1100
Subject: [wildfly-dev] Policies for merging PRs on master
In-Reply-To: <CAPhbRDY7rsynXLy1HR0+Cg5JLS_+CVBx3G+4QNuWXpW6aW2BfA@mail.gmail.com>
References: <CAKQecn95fhbz4w7SMBoc+QvSCbcyJ=7MsK_2V3QOqU-2Ja5xrQ@mail.gmail.com>
	<CANghgrRT+qD351=s0cNP24Rjz5ny9Ys8Axy3K-chbxQ8d+iPuw@mail.gmail.com>
	<CAKQecn-UrxaYG=Q-ELYLqDti0vcRzY-LwYCicbV600xqnUuULg@mail.gmail.com>
	<CAPhbRDY7rsynXLy1HR0+Cg5JLS_+CVBx3G+4QNuWXpW6aW2BfA@mail.gmail.com>
Message-ID: <CAAoo=c6kTt9j-8moNkR1aDML0Mz88j0_y3x7G6Jwj_ctM_jncQ@mail.gmail.com>

On Tue, Dec 5, 2017 at 3:40 AM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> Great. :)
>
> One thing I think we need to do is figure out how to get custom TCK runs
> for PR branches. The TCK is a big part of our test coverage, and one way to
> not "use master as a test bed" is to get a check of a branch on the TCK
> before we merge it.
>
> I know we've gotten TCK runs of ad-hoc branches before, so by "figure out"
> I mean work out how to make that not overly painful, come to some sort of
> consensus on when it's worthwhile, etc.
>

I think if we were going to do this it should probably be something
reviewers can ask for on specific PR. The TCK uses a *lot* more resources
than a standard CI run, so we need to make sure we limit it to cases where
it is required.

Stuart



>
> On Fri, Dec 1, 2017 at 10:04 AM, Alessio Soldano <asoldano at redhat.com>
> wrote:
>
>> There you go... PR updated to consume the same api jar now released as
>> final.
>>
>> Cheers
>> Alessio
>>
>> On Fri, Dec 1, 2017 at 3:30 PM, David Lloyd <david.lloyd at redhat.com>
>> wrote:
>>
>>> On Thu, Nov 30, 2017 at 5:50 PM, Alessio Soldano <asoldano at redhat.com>
>>> wrote:
>>> > As suggested by Brian, I'd like to draw attention to the discussion on
>>> > https://github.com/wildfly/wildfly/pull/10604 .
>>> > The PR is an upgrade of the webservices stack, including JBossWS,
>>> Apache
>>> > CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade is for EE8
>>> and
>>> > better JDK 9 compatibility.
>>> > Now, due to the upgrade of the JAXB API spec jar, the PR is essentially
>>> > stalled since 20 days; the new spec is released as an alpha (as it's
>>> been
>>> > tested within JBossWS only) and that does not satisfy a rule that
>>> requires
>>> > any artifact being pulled to be Final.
>>> > We're talking about a spec jar, we could simply re-tag that as Final,
>>> > chances are we won't need changes any time soon there anyway, but as
>>> Tomaz
>>> > pointed out, in principle that would be dishonest.
>>>
>>> My opinion is that you should go ahead and make a .Final tag.  In the
>>> (unlikely?) event that the spec has to be modified for some reason, I
>>> think you could make a 1.0.1.Final tag and call it a "bug fix".
>>>
>>> The alternative is to simply wait.  I don't think there is any middle
>>> position.
>>>
>>> > While I see the point in requiring that only sufficiently stable
>>> upgrades
>>> > are applied to the codebase, I'm wondering whether, maybe, we're going
>>> a bit
>>> > too far with the rules. Brian wrote on this topic: "how to determine
>>> that
>>> > something is good enough to go in without using master as a test bed" ?
>>>
>>> I don't think we are; I agree with the policy as it stands.  If you
>>> look at it in terms of being able to release at any time, then it
>>> follows that everything _must_ be stable.
>>>
>>> --
>>> - DML
>>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> 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/20171205/e8896c37/attachment.html 

From smarlow at redhat.com  Tue Dec  5 05:37:50 2017
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 5 Dec 2017 05:37:50 -0500
Subject: [wildfly-dev] Policies for merging PRs on master
In-Reply-To: <CAAoo=c6kTt9j-8moNkR1aDML0Mz88j0_y3x7G6Jwj_ctM_jncQ@mail.gmail.com>
References: <CAKQecn95fhbz4w7SMBoc+QvSCbcyJ=7MsK_2V3QOqU-2Ja5xrQ@mail.gmail.com>
	<CANghgrRT+qD351=s0cNP24Rjz5ny9Ys8Axy3K-chbxQ8d+iPuw@mail.gmail.com>
	<CAKQecn-UrxaYG=Q-ELYLqDti0vcRzY-LwYCicbV600xqnUuULg@mail.gmail.com>
	<CAPhbRDY7rsynXLy1HR0+Cg5JLS_+CVBx3G+4QNuWXpW6aW2BfA@mail.gmail.com>
	<CAAoo=c6kTt9j-8moNkR1aDML0Mz88j0_y3x7G6Jwj_ctM_jncQ@mail.gmail.com>
Message-ID: <1bdbcb2e-2a87-3218-b7ba-01728d7d2596@redhat.com>

It would be great if we could have a branch that includes all of the 
commits that we are considering to merge at a particular time of day, 
such that we would run the TCK against that branch, only once a day.  If 
one of the changes cause a TCK failure, none of them get merged 
(investigation follows that to determine which change caused the 
failure(s)), if the test succeeds, we can then merge that batch of 
changes into WildFly master.

We likely would want to avoid running the testing, on days when we 
haven't merged any changes to the WF testing branching.

Would that approach help how we merge PRs on master?

Scott

On 12/04/2017 09:33 PM, Stuart Douglas wrote:
> 
> 
> On Tue, Dec 5, 2017 at 3:40 AM, Brian Stansberry 
> <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
> 
>     Great. :)
> 
>     One thing I think we need to do is figure out how to get custom TCK
>     runs for PR branches. The TCK is a big part of our test coverage,
>     and one way to not "use master as a test bed" is to get a check of a
>     branch on the TCK before we merge it.
> 
>     I know we've gotten TCK runs of ad-hoc branches before, so by
>     "figure out" I mean work out how to make that not overly painful,
>     come to some sort of consensus on when it's worthwhile, etc.
> 
> 
> I think if we were going to do this it should probably be something 
> reviewers can ask for on specific PR. The TCK uses a *lot* more 
> resources than a standard CI run, so we need to make sure we limit it to 
> cases where it is required.
> 
> Stuart
> 
> 
>     On Fri, Dec 1, 2017 at 10:04 AM, Alessio Soldano
>     <asoldano at redhat.com <mailto:asoldano at redhat.com>> wrote:
> 
>         There you go... PR updated to consume the same api jar now
>         released as final.
> 
>         Cheers
>         Alessio
> 
>         On Fri, Dec 1, 2017 at 3:30 PM, David Lloyd
>         <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>> wrote:
> 
>             On Thu, Nov 30, 2017 at 5:50 PM, Alessio Soldano
>             <asoldano at redhat.com <mailto:asoldano at redhat.com>> wrote:
>             > As suggested by Brian, I'd like to draw attention to the discussion on
>             > https://github.com/wildfly/wildfly/pull/10604
>             <https://github.com/wildfly/wildfly/pull/10604> .
>             > The PR is an upgrade of the webservices stack, including JBossWS, Apache
>             > CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade is for EE8 and
>             > better JDK 9 compatibility.
>             > Now, due to the upgrade of the JAXB API spec jar, the PR is essentially
>             > stalled since 20 days; the new spec is released as an alpha (as it's been
>             > tested within JBossWS only) and that does not satisfy a rule that requires
>             > any artifact being pulled to be Final.
>             > We're talking about a spec jar, we could simply re-tag that as Final,
>             > chances are we won't need changes any time soon there anyway, but as Tomaz
>             > pointed out, in principle that would be dishonest.
> 
>             My opinion is that you should go ahead and make a .Final
>             tag.? In the
>             (unlikely?) event that the spec has to be modified for some
>             reason, I
>             think you could make a 1.0.1.Final tag and call it a "bug fix".
> 
>             The alternative is to simply wait.? I don't think there is
>             any middle position.
> 
>             > While I see the point in requiring that only sufficiently stable upgrades
>             > are applied to the codebase, I'm wondering whether, maybe, we're going a bit
>             > too far with the rules. Brian wrote on this topic: "how to determine that
>             > something is good enough to go in without using master as a test bed" ?
> 
>             I don't think we are; I agree with the policy as it stands. 
>             If you
>             look at it in terms of being able to release at any time,
>             then it
>             follows that everything _must_ be stable.
> 
>             --
>             - DML
> 
> 
> 
>         _______________________________________________
>         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
>         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> 
> 
> 
> 
>     -- 
>     Brian Stansberry
>     Manager, Senior Principal Software Engineer
>     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
>     <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 brian.stansberry at redhat.com  Tue Dec  5 08:44:29 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 5 Dec 2017 07:44:29 -0600
Subject: [wildfly-dev] Policies for merging PRs on master
In-Reply-To: <CAPhbRDY2yjKdFG0eytAkQfktA_8u-QorgPRSXLsHAdnE0hX_Vg@mail.gmail.com>
References: <CAKQecn95fhbz4w7SMBoc+QvSCbcyJ=7MsK_2V3QOqU-2Ja5xrQ@mail.gmail.com>
	<CANghgrRT+qD351=s0cNP24Rjz5ny9Ys8Axy3K-chbxQ8d+iPuw@mail.gmail.com>
	<CAKQecn-UrxaYG=Q-ELYLqDti0vcRzY-LwYCicbV600xqnUuULg@mail.gmail.com>
	<CAPhbRDY7rsynXLy1HR0+Cg5JLS_+CVBx3G+4QNuWXpW6aW2BfA@mail.gmail.com>
	<CAAoo=c6kTt9j-8moNkR1aDML0Mz88j0_y3x7G6Jwj_ctM_jncQ@mail.gmail.com>
	<CAPhbRDY2yjKdFG0eytAkQfktA_8u-QorgPRSXLsHAdnE0hX_Vg@mail.gmail.com>
Message-ID: <CAPhbRDbO6rrr4DuJi0jvEGMNBjy-Jpb5kgci9KXM_pky4Y+zTw@mail.gmail.com>

Sorry, I dropped the list on my last post; see below...

On Tue, Dec 5, 2017 at 7:42 AM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> On Mon, Dec 4, 2017 at 8:33 PM, Stuart Douglas <stuart.w.douglas at gmail.com
> > wrote:
>
>>
>>
>> On Tue, Dec 5, 2017 at 3:40 AM, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>>
>>> Great. :)
>>>
>>> One thing I think we need to do is figure out how to get custom TCK runs
>>> for PR branches. The TCK is a big part of our test coverage, and one way to
>>> not "use master as a test bed" is to get a check of a branch on the TCK
>>> before we merge it.
>>>
>>> I know we've gotten TCK runs of ad-hoc branches before, so by "figure
>>> out" I mean work out how to make that not overly painful, come to some sort
>>> of consensus on when it's worthwhile, etc.
>>>
>>
>> I think if we were going to do this it should probably be something
>> reviewers can ask for on specific PR. The TCK uses a *lot* more resources
>> than a standard CI run, so we need to make sure we limit it to cases where
>> it is required.
>>
>
> Yes, for sure we wouldn't want to do this broadly; submitters or reviewers
> should ask.
>
> I had in mind a fairly limited set of scenarios. Things like major/minor
> version bumps of the big EE components, or some large scale change with
> fairly clear TCK implications where we'd be reluctant to undo the change if
> it caused a problem. *Perhaps* core upgrades, as those somewhat amount to
> the latter. And then late in the cycle some last minute fixes where we
> sometimes ask for a custom run anyway.
>
> Doing custom runs doesn't buy much for small changes where if they fail
> TCK after merge we just revert them or we can spend a few days sorting the
> problem without stressing out.
>
>
>> Stuart
>>
>>
>>
>>>
>>> On Fri, Dec 1, 2017 at 10:04 AM, Alessio Soldano <asoldano at redhat.com>
>>> wrote:
>>>
>>>> There you go... PR updated to consume the same api jar now released as
>>>> final.
>>>>
>>>> Cheers
>>>> Alessio
>>>>
>>>> On Fri, Dec 1, 2017 at 3:30 PM, David Lloyd <david.lloyd at redhat.com>
>>>> wrote:
>>>>
>>>>> On Thu, Nov 30, 2017 at 5:50 PM, Alessio Soldano <asoldano at redhat.com>
>>>>> wrote:
>>>>> > As suggested by Brian, I'd like to draw attention to the discussion
>>>>> on
>>>>> > https://github.com/wildfly/wildfly/pull/10604 .
>>>>> > The PR is an upgrade of the webservices stack, including JBossWS,
>>>>> Apache
>>>>> > CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade is for
>>>>> EE8 and
>>>>> > better JDK 9 compatibility.
>>>>> > Now, due to the upgrade of the JAXB API spec jar, the PR is
>>>>> essentially
>>>>> > stalled since 20 days; the new spec is released as an alpha (as it's
>>>>> been
>>>>> > tested within JBossWS only) and that does not satisfy a rule that
>>>>> requires
>>>>> > any artifact being pulled to be Final.
>>>>> > We're talking about a spec jar, we could simply re-tag that as Final,
>>>>> > chances are we won't need changes any time soon there anyway, but as
>>>>> Tomaz
>>>>> > pointed out, in principle that would be dishonest.
>>>>>
>>>>> My opinion is that you should go ahead and make a .Final tag.  In the
>>>>> (unlikely?) event that the spec has to be modified for some reason, I
>>>>> think you could make a 1.0.1.Final tag and call it a "bug fix".
>>>>>
>>>>> The alternative is to simply wait.  I don't think there is any middle
>>>>> position.
>>>>>
>>>>> > While I see the point in requiring that only sufficiently stable
>>>>> upgrades
>>>>> > are applied to the codebase, I'm wondering whether, maybe, we're
>>>>> going a bit
>>>>> > too far with the rules. Brian wrote on this topic: "how to determine
>>>>> that
>>>>> > something is good enough to go in without using master as a test
>>>>> bed" ?
>>>>>
>>>>> I don't think we are; I agree with the policy as it stands.  If you
>>>>> look at it in terms of being able to release at any time, then it
>>>>> follows that everything _must_ be stable.
>>>>>
>>>>> --
>>>>> - DML
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> Red Hat
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171205/b331dc20/attachment-0001.html 

From brian.stansberry at redhat.com  Tue Dec  5 08:57:27 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 5 Dec 2017 07:57:27 -0600
Subject: [wildfly-dev] Policies for merging PRs on master
In-Reply-To: <1bdbcb2e-2a87-3218-b7ba-01728d7d2596@redhat.com>
References: <CAKQecn95fhbz4w7SMBoc+QvSCbcyJ=7MsK_2V3QOqU-2Ja5xrQ@mail.gmail.com>
	<CANghgrRT+qD351=s0cNP24Rjz5ny9Ys8Axy3K-chbxQ8d+iPuw@mail.gmail.com>
	<CAKQecn-UrxaYG=Q-ELYLqDti0vcRzY-LwYCicbV600xqnUuULg@mail.gmail.com>
	<CAPhbRDY7rsynXLy1HR0+Cg5JLS_+CVBx3G+4QNuWXpW6aW2BfA@mail.gmail.com>
	<CAAoo=c6kTt9j-8moNkR1aDML0Mz88j0_y3x7G6Jwj_ctM_jncQ@mail.gmail.com>
	<1bdbcb2e-2a87-3218-b7ba-01728d7d2596@redhat.com>
Message-ID: <CAPhbRDaAVT5RPuY1bd1+Ayi3rYaJGWDuotkiFTGo5vCLEgz4Jg@mail.gmail.com>

On Tue, Dec 5, 2017 at 4:37 AM, Scott Marlow <smarlow at redhat.com> wrote:

> It would be great if we could have a branch that includes all of the
> commits that we are considering to merge at a particular time of day, such
> that we would run the TCK against that branch, only once a day.


Can this be done that often? I had in my mind that if we did one of these
it would amount to stealing one of the regular runs, but perhaps that's not
the case.

Now, I don't think we'd want to do these anywhere near that often, but it's
good to know what the limits would be. For example, I could imagine doing
10 of these over the course of a WF release, but by luck or whatever 3 of
them come in the same week.

+1 to using a branch. We have a branch like that, master-ignore, that we
use for batching up PRs to test as a group before merging. I wouldn't want
to use master-ignore for this, but a differently named branch run the same
way sounds good.


> If one of the changes cause a TCK failure, none of them get merged
> (investigation follows that to determine which change caused the
> failure(s)), if the test succeeds, we can then merge that batch of changes
> into WildFly master.
>
> We likely would want to avoid running the testing, on days when we haven't
> merged any changes to the WF testing branching.
>
>
Can the TCK be set up to run based on a check for a change in the sha of
the head of a branch? So every day at a fixed time it checks the branch,
and does nothing if there is no change. If we want a run, we force push the
branch before that time. We have CI jobs that check master-ignore that way,
except they poll regularly, not just once a day. That works for those as
they aren't so resource intensive that we worry a lot about limiting how
often they run.


> Would that approach help how we merge PRs on master?
>
>
I think it could be helpful earlier in the release cycle before merging big
changes, and then perhaps late in the release cycle  if we're worried about
possible regressions.

Scott
>
> On 12/04/2017 09:33 PM, Stuart Douglas wrote:
>
>>
>>
>> On Tue, Dec 5, 2017 at 3:40 AM, Brian Stansberry <
>> brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>> wrote:
>>
>>     Great. :)
>>
>>     One thing I think we need to do is figure out how to get custom TCK
>>     runs for PR branches. The TCK is a big part of our test coverage,
>>     and one way to not "use master as a test bed" is to get a check of a
>>     branch on the TCK before we merge it.
>>
>>     I know we've gotten TCK runs of ad-hoc branches before, so by
>>     "figure out" I mean work out how to make that not overly painful,
>>     come to some sort of consensus on when it's worthwhile, etc.
>>
>>
>> I think if we were going to do this it should probably be something
>> reviewers can ask for on specific PR. The TCK uses a *lot* more resources
>> than a standard CI run, so we need to make sure we limit it to cases where
>> it is required.
>>
>> Stuart
>>
>>
>>     On Fri, Dec 1, 2017 at 10:04 AM, Alessio Soldano
>>     <asoldano at redhat.com <mailto:asoldano at redhat.com>> wrote:
>>
>>         There you go... PR updated to consume the same api jar now
>>         released as final.
>>
>>         Cheers
>>         Alessio
>>
>>         On Fri, Dec 1, 2017 at 3:30 PM, David Lloyd
>>         <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>> wrote:
>>
>>             On Thu, Nov 30, 2017 at 5:50 PM, Alessio Soldano
>>             <asoldano at redhat.com <mailto:asoldano at redhat.com>> wrote:
>>             > As suggested by Brian, I'd like to draw attention to the
>> discussion on
>>             > https://github.com/wildfly/wildfly/pull/10604
>>             <https://github.com/wildfly/wildfly/pull/10604> .
>>             > The PR is an upgrade of the webservices stack, including
>> JBossWS, Apache
>>             > CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade
>> is for EE8 and
>>             > better JDK 9 compatibility.
>>             > Now, due to the upgrade of the JAXB API spec jar, the PR is
>> essentially
>>             > stalled since 20 days; the new spec is released as an alpha
>> (as it's been
>>             > tested within JBossWS only) and that does not satisfy a
>> rule that requires
>>             > any artifact being pulled to be Final.
>>             > We're talking about a spec jar, we could simply re-tag that
>> as Final,
>>             > chances are we won't need changes any time soon there
>> anyway, but as Tomaz
>>             > pointed out, in principle that would be dishonest.
>>
>>             My opinion is that you should go ahead and make a .Final
>>             tag.  In the
>>             (unlikely?) event that the spec has to be modified for some
>>             reason, I
>>             think you could make a 1.0.1.Final tag and call it a "bug
>> fix".
>>
>>             The alternative is to simply wait.  I don't think there is
>>             any middle position.
>>
>>             > While I see the point in requiring that only sufficiently
>> stable upgrades
>>             > are applied to the codebase, I'm wondering whether, maybe,
>> we're going a bit
>>             > too far with the rules. Brian wrote on this topic: "how to
>> determine that
>>             > something is good enough to go in without using master as a
>> test bed" ?
>>
>>             I don't think we are; I agree with the policy as it stands.
>>            If you
>>             look at it in terms of being able to release at any time,
>>             then it
>>             follows that everything _must_ be stable.
>>
>>             --
>>             - DML
>>
>>
>>
>>         _______________________________________________
>>         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
>>         <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>
>>
>>
>>
>>     --     Brian Stansberry
>>     Manager, Senior Principal Software Engineer
>>     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
>>     <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
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171205/c4b45801/attachment.html 

From david.lloyd at redhat.com  Tue Dec  5 11:10:16 2017
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 5 Dec 2017 10:10:16 -0600
Subject: [wildfly-dev] Java 9, JBoss Modules, JAXP Redirection
Message-ID: <CANghgrS=QWkt6rWt-EJZiWbh27xUFuu1gutT9b_LTPofSVCeFA@mail.gmail.com>

JBoss Modules has a redirection mechanism for JAXP that allows us to
override the default provider with one from a module, while still
allowing TCCL-based selection to occur.  Since Java 9, our
implementation violates the stricter reflection rules that are now in
place, meaning that JBoss Modules will probably stop working in a
future version.  We had hoped that Java 9 would have some useful way
to establish the default implementation of various JAXP factories, but
that never happened.  So I want to take the opportunity to review a
few mitigation options and get some feedback.

Option 1: Fix the redirection facility in Java 9

Java 9 offers a "newDefaultFactory()" method on most (maybe all) of
the JAXP factory classes, which always simply instantiates the system
provider of the given function.  Using this method should allow us to
bypass the now-disallowed reflection by switching all of the cached
Constructor<? extends T> fields with cached Supplier<T> fields, whose
implementation would either be a call to the appropriate
newDefaultFactory() or a service loader-style public Constructor call.

Pros:
? Less change
? We can still override the default JAXP implementation

Cons:
? Continue carrying around the baggage of the __redirected code
until/unless the JAXP spec is modified to allow setting the default
factories

Option 2: Stop using redirection in Java 9, "cold turkey"

We could delete these classes completely.  Instead of setting the
default JAXP implementation, we ensure that any modules using JAXP
have a services dependency on the implementation(s) corresponding to
those APIs, carefully monitoring TCCL setup and usage or ensuring that
the newFactory(xxx, getClass().getClassLoader()) form is always used,
depending on the situation.

Pros:
? No more dealing with redirection ever again
? While deployments generally use the newFactory() form, but
deployments also have TCCL set so that's not a problem
? One less source of bugs

Cons:
? It may be hard to be sure that we've done this 100% correctly in all
cases outside of deployments; the results could be weird mixed
implementations

Option 3: Use a dependency strategy

We could cause JBoss Modules to always include a "hidden" last
dependency on our chosen default JAXP implementation, which in turn
could be set up by a service loader configuration in the boot module.

Pros:
? Simpler than redirection

Cons:
? Due to the way JAXP works, we have to pollute the target module's
namespace with the implementation classes (though with redirection
we've already done that via __redirected classes)

So far Option 1 is (unfortunately) still looking the best to me,
overall.  Does anyone have any differing opinions on this?

-- 
- DML


From brian.stansberry at redhat.com  Tue Dec  5 13:22:26 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 5 Dec 2017 12:22:26 -0600
Subject: [wildfly-dev] WildFly 11 and JDK9
In-Reply-To: <CAFdSV9spb5BzSnZBPDdewOxxg62RfbjirmmqaST68wVqUYiGSg@mail.gmail.com>
References: <CAMquZP4-aXwQnM-BaFnF699MPONs6FMetOZYOyeKWAqvrxMUQQ@mail.gmail.com>
	<70A2E4B2-B786-4B32-8A1F-2E5D75803649@redhat.com>
	<CAFdSV9spb5BzSnZBPDdewOxxg62RfbjirmmqaST68wVqUYiGSg@mail.gmail.com>
Message-ID: <CAPhbRDYy_-9F6vBYngFcJqZhypDpBDkh9NFHBTxBcQSzg9wRqA@mail.gmail.com>

There's a Javassist 3.22.0-GA out and we've moved on to WF 12 work. What
are we going to do about this one?

We don't expect a long dev cycle for WF 12 so if we are going to make this
change we shouldn't delay long. We don't want to try it and see right
before the release.

On Thu, Aug 31, 2017 at 10:24 AM, Steve Ebersole <steve at hibernate.org>
wrote:

> I guess we'd have to TIAS.  Generally history tells us that these
> Javassist updates do not go smoothly for Hibernate/WF.  However, at least
> part of purpose of this 3.22 release was for Hibernate and Java 9:
> https://issues.jboss.org/browse/JASSIST-261
>
> Back then I was able to use those 3.22 snapshots successfully, so
> hopefully this upgrade should go smoothly.  But I agree that I would feel
> more comfortable with a Final rather than a CR.
>
>
> On Thu, Aug 31, 2017 at 10:14 AM Jason Greene <jason.greene at redhat.com>
> wrote:
>
>> I think its probably too late, but I think we can follow up with an 11.1
>> or 11.0.1 that includes Java 9 fixes.
>>
>> I suspect we probably won?t have everything even if we did update
>> Javassist (still some test failures etc).
>>
>> If someone has a strong argument otherwise, speak now or forever hold
>> your peace!
>>
>> On Aug 31, 2017, at 8:21 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>>
>> Hey guys,
>>
>> during development of WF11 we have done lots of work on making it build &
>> run on JDK9.
>> as release nears I would like to summarize what the current state is and
>> how to move on.
>>
>> Currently most of our core [1] & full [2] testsuite passes on latest
>> builds of JDK9.
>> Remaining failures are already addressed by [3] and [4]
>>
>> **But** passing testsuite on JDK9 is not the same as using our binary
>> distribution under JDK9.
>>
>> Currently as part of running build / testsuite we override version of
>> javassit to 3.22.0-CR2
>> which is currently the only version that works properly on JDK9.
>> As there is no .GA version of javassit that work on JDK9 avalible we
>> currently do not have it as default.
>>
>> On top of that, hibernate as main user of javassit is not tested enough
>> with this version of javassist
>> unless hibernate / JPA team says otherwise.
>>
>> That would in practice mean that users running WF11 on JDK9 would have
>> issues with JPA/Hibernate
>> based applications.
>>
>> Currently I see two options how to address this:
>> - upgrade javassist to 3.22.x in server, preferably ask for .GA release.
>> - produce additional WildFly.x.x.x-jdk9 zip that would include the newer
>> javassist.
>>
>> So question is do we even want to have working JDK9 build of WildFly 11
>> .Final
>> or should we postpone this for next update release.
>>
>> --
>> tomaz
>>
>>
>> [1] https://ci.wildfly.org/viewType.html?buildTypeId=
>> WildFlyCore_MasterLinuxJdk9
>> [2] https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea
>> [3] https://github.com/wildfly/wildfly-core/pull/2738
>> [4] https://github.com/wildfly/wildfly-core/pull/2751
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> --
>> Jason T. Greene
>> Chief Architect, JBoss EAP
>> Red Hat
>>
>> _______________________________________________
>> 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
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171205/bc358bda/attachment-0001.html 

From tomaz.cerar at gmail.com  Tue Dec  5 17:29:17 2017
From: tomaz.cerar at gmail.com (=?utf-8?Q?Toma=C5=BE_Cerar?=)
Date: Tue, 5 Dec 2017 23:29:17 +0100
Subject: [wildfly-dev] Java 9, JBoss Modules, JAXP Redirection
In-Reply-To: <CANghgrS=QWkt6rWt-EJZiWbh27xUFuu1gutT9b_LTPofSVCeFA@mail.gmail.com>
References: <CANghgrS=QWkt6rWt-EJZiWbh27xUFuu1gutT9b_LTPofSVCeFA@mail.gmail.com>
Message-ID: <5a271dbb.2d8fdf0a.b0cf.9567@mx.google.com>

I am more in favor of option 2. 
As long as we can make it work.

We already tried moving to JAXP completely quite recently,  but we did stumble upon few issues. 
Mostly related to not fully compatible JAXP factory classes used by some of EE spec APIs 
which haven?t been updated in a while. 
One of such was SAAJ api https://github.com/jboss/jboss-saaj-api_spec
Along with few others in the webservices area.

If we can make it work going forward, it will probably be best benefit for us all.

I don?t think deployments themselves pose any big issues now days. 
Bigger problems are libraries  / subsystems that we integrate. Especially some more arcane parts of EE stack.

--
tomaz


From: David Lloyd
Sent: torek, 05. december 2017 17:43
To: WildFly Dev
Subject: [wildfly-dev] Java 9, JBoss Modules, JAXP Redirection

JBoss Modules has a redirection mechanism for JAXP that allows us to
override the default provider with one from a module, while still
allowing TCCL-based selection to occur.  Since Java 9, our
implementation violates the stricter reflection rules that are now in
place, meaning that JBoss Modules will probably stop working in a
future version.  We had hoped that Java 9 would have some useful way
to establish the default implementation of various JAXP factories, but
that never happened.  So I want to take the opportunity to review a
few mitigation options and get some feedback.

Option 1: Fix the redirection facility in Java 9

Java 9 offers a "newDefaultFactory()" method on most (maybe all) of
the JAXP factory classes, which always simply instantiates the system
provider of the given function.  Using this method should allow us to
bypass the now-disallowed reflection by switching all of the cached
Constructor<? extends T> fields with cached Supplier<T> fields, whose
implementation would either be a call to the appropriate
newDefaultFactory() or a service loader-style public Constructor call.

Pros:
? Less change
? We can still override the default JAXP implementation

Cons:
? Continue carrying around the baggage of the __redirected code
until/unless the JAXP spec is modified to allow setting the default
factories

Option 2: Stop using redirection in Java 9, "cold turkey"

We could delete these classes completely.  Instead of setting the
default JAXP implementation, we ensure that any modules using JAXP
have a services dependency on the implementation(s) corresponding to
those APIs, carefully monitoring TCCL setup and usage or ensuring that
the newFactory(xxx, getClass().getClassLoader()) form is always used,
depending on the situation.

Pros:
? No more dealing with redirection ever again
? While deployments generally use the newFactory() form, but
deployments also have TCCL set so that's not a problem
? One less source of bugs

Cons:
? It may be hard to be sure that we've done this 100% correctly in all
cases outside of deployments; the results could be weird mixed
implementations

Option 3: Use a dependency strategy

We could cause JBoss Modules to always include a "hidden" last
dependency on our chosen default JAXP implementation, which in turn
could be set up by a service loader configuration in the boot module.

Pros:
? Simpler than redirection

Cons:
? Due to the way JAXP works, we have to pollute the target module's
namespace with the implementation classes (though with redirection
we've already done that via __redirected classes)

So far Option 1 is (unfortunately) still looking the best to me,
overall.  Does anyone have any differing opinions on this?

-- 
- DML

_______________________________________________
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/20171205/806b0ba6/attachment.html 

From belaran at redhat.com  Wed Dec  6 05:27:42 2017
From: belaran at redhat.com (Romain Pelisse)
Date: Wed, 6 Dec 2017 11:27:42 +0100
Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have
 POSIX permissions perfectly set
In-Reply-To: <CAPhbRDYN_PGP8fo6BizQ3EOR-=9UT_jrJEECzLBfT-DoOt05fg@mail.gmail.com>
References: <CALuBA_p5Mqag2+TSD9bUWGM5BgDpirdZC7zvL5OE8w-HfA4AWw@mail.gmail.com>
	<CAPhbRDYyGwNpqFq8bYdRk53_hx6Mg4yHwOcmmYYnwDp_3-B+_A@mail.gmail.com>
	<CALuBA_pSvfNYPug1byQrS7Bic45vVvvdQ4Mjd-BQ6Pa4t5m05g@mail.gmail.com>
	<CAPhbRDYnYLd-SXuE_m_2b14W9VwNhy08KDpC0MdP6n3mipMi0A@mail.gmail.com>
	<CAPhbRDZFTd52gO8-psaaXJSVNAPn=3MtjA3XuyEC501Hj-rRJw@mail.gmail.com>
	<CALuBA_pXT89PNspojT-sT3GNTVhf1R1F7YJPxn7K-B6dmP4+bg@mail.gmail.com>
	<CAPhbRDZFfcuS5kZNHU99cVDSTjewsVynuaZAAxsxdQSswxOZOA@mail.gmail.com>
	<CAPhbRDYN_PGP8fo6BizQ3EOR-=9UT_jrJEECzLBfT-DoOt05fg@mail.gmail.com>
Message-ID: <CALuBA_qxu=nGP93yfPXEdhiUdxBkQ2C7YZx=82i7qbOA=egr+A@mail.gmail.com>

Hi Brian (and all),

I honestly understand your resistance, and I'm completely fine if we end up
closing this all issue as WONTDO or REJECTED. I just do want to have a
discussion about it and come back with clear reasons and motivations for
changing or not the privileges of each of those files.

Given that we see different things on our local setup, I think the best
will be to use a build on a CI Server and works from what we see there. Is
there an easy way for me to clone a job building Wildfly and tweak it on
some (publicly) accessible instance ?


On Mon, Dec 4, 2017 at 6:48 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> A slightly different topic, related to the "logging.properties/xml config
> file" topic is whether these files should be world and/or group readable.
>
> Changing this has been proposed in the past on the EAP side, primarily
> based on the argument that users could put sensitive data in these files.
> This thread seems like a good time to debate this a bit in community.
>
> I've resisted that primarily on the basis of:
>
> 1) These files or those similarly used have had these perms as far back as
> I can find in JBoss AS. So the odds that some people are relying upon those
> perms is fairly high and we need to assume a change would be a breaking
> change for some people.
>
> 2) Other software I've looked at like Tomcat and httpd have similar
> permission schemes to what we have for their config files, which can also
> potentially include sensitive data.
>
> 3) We provide facilities like the vault or elytron credential store refs
> for keeping sensitive data out of the config files.
>
>
> On Mon, Dec 4, 2017 at 11:38 AM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>> Thanks, Romain.
>>
>> Re: what the actual permissions are, FWIW I get what I see on both my
>> macbook and my Fedora 27 machine, both when unzipping the actual
>> 11.0.0.Final and when unzipping the result of a build of master, and both
>> with and without the -Prelease -Pjboss-release args to maven that we
>> include when doing actual releases. Unzipping the zip in build/target
>> doesn't include the jars of course.
>>
>> So it sounds like we need input from others.
>>
>> Re: modules.xml, if you are seeing those as rw-r--r-- as well, then +1 to
>> ignoring them in further discussion.
>>
>> Re: logging.properties, those serve a very similar conceptual role to the
>> standalone|host|domain.xml files so I see no reason for them to have
>> different perms. However, you and I are getting different results, where
>> you report them as group writable and I don't. What do you see for the xml
>> config files?
>>
>> Re: RPM changing to match WildFly, that's an EAP discussion, so that can
>> be taken up elsewhere once we have WildFly the way we want it.
>>
>>
>> On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse <belaran at redhat.com>
>> wrote:
>>
>>> Hi Brian and all,
>>>
>>> err, my own observation differs from yours. I've rebuild Wildfly from
>>> the last content of the master branch and get the same privileges on the
>>> jboss-modules.jar (so -rw-rw-r-- and not as you are seeing  rwxr--r--).
>>> Same with the domain folder, which turns out on my local system associated
>>> to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a
>>> transcript of what I did - maybe you can spot why our results differs so
>>> much.
>>>
>>> $ git show
>>> commit 46e119c65d9e32bc0ec69f3933267fece959ed3f
>>> Merge: 051f080 c7d9075
>>> Author: Kabir Khan <kkhan at redhat.com>
>>> Date:   Tue Nov 28 17:46:40 2017 +0000
>>>
>>>     Merge pull request #10669 from praxeo/WFLY-9284
>>>
>>>     WFLY-9284 Correct MVN env variable to mvnw.cmd
>>>
>>> $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d
>>> wildfly-12.zip
>>> ...
>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
>>> -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov.  11:41
>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/  -d
>>> drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov.  11:41
>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/
>>>
>>> Checking all the jars in the distribution, they all appears to have the
>>> mask '-rw-rw-r--':
>>>
>>> $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done | sed
>>> -e '/-rw-rw-r--/d'
>>> $
>>>
>>> Regarding properties files, here is the exhaustive list of properties
>>> that RPM packaging has modified the privileges of:
>>>
>>> appclient/configuration/logging.properties rw-------
>>> domain/configuration/application-roles.properties rw-------
>>> domain/configuration/default-server-logging.properties rw-------
>>> domain/configuration/logging.properties rw-------
>>> domain/configuration/mgmt-groups.properties rw-------
>>> standalone/configuration/application-roles.properties rw-------
>>> standalone/configuration/logging.properties rw-------
>>> standalone/configuration/mgmt-groups.properties rw-------
>>>
>>> If I compare that with the content of the extract zip (same fresh built
>>> as above), I can see that 4 files are not having the same mask (rw------):
>>>
>>> $ for file in $(cut -f1 -d\  ../../../list-props-files.txt ); do ls -l
>>> $file ; done
>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>> appclient/configuration/logging.properties
>>> -rw-------. 1 rpelisse rpelisse 710 30 nov.  11:41
>>> domain/configuration/application-roles.properties
>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>> domain/configuration/default-server-logging.properties
>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>> domain/configuration/logging.properties
>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>> domain/configuration/mgmt-groups.properties
>>> -rw-------. 1 rpelisse rpelisse 711 30 nov.  11:41
>>> standalone/configuration/application-roles.properties
>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>> standalone/configuration/logging.properties
>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>> standalone/configuration/mgmt-groups.properties
>>>
>>> Now, as you said, those files privileges are indeed fine-grained, so
>>> maybe we can push back to people making the RPM for them to NOT change the
>>> following files privileges:
>>>
>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>> appclient/configuration/logging.properties
>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>> domain/configuration/default-server-logging.properties
>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>> domain/configuration/logging.properties
>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>> standalone/configuration/logging.properties
>>>
>>> However, I don't see the value of letting those files accessible either
>>> group member or any user on the system, but maybe we can make the argument
>>> they should. But the write privileges for group member sounds wrong to me.
>>>
>>> Also, I'm puzzled Brian and I are seeing different things - am I looking
>>> at the correct zipfile here ?
>>>
>>> Note: You also mention the module.xml - as far as I can see from the
>>> diff provided with issue JBEAP-12374, I don't see any issue with privileges
>>> regarding those files, so we can remove them of the discussion. The only
>>> changes we need to discuss is removing the 'write' privileges' for the
>>> group on jars, reducing the scope of permissions on (some) folders, and
>>> privileges on (some) properties files. So, module.xml are out of the scope.
>>>
>>> On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry <
>>> brian.stansberry at redhat.com> wrote:
>>>
>>>> Seems I forgot to "Reply to All" yesterday. The following was meant to
>>>> be sent to wildfly-dev.
>>>>
>>>> On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry <
>>>> brian.stansberry at redhat.com> wrote:
>>>>
>>>>> Before getting into the specifics, first a general note re: perms.
>>>>>
>>>>> Our general permission set for is rwxr-xr-x for directories and
>>>>> rwxr--r-- for files. If someone thinks that's wrong in general; speak up.
>>>>> ;). Otherwise I think any deviation from that we should justify. Not that
>>>>> deviations are wrong, just that they need to have a reason.
>>>>>
>>>>> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <belaran at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Well, the diff is between the RPM and the zipfile is pretty long, but
>>>>>> it boils down to the 3 set of differences I've pointed out on
>>>>>> WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574>
>>>>>>
>>>>>>    - *.properties and .jar* files are associated with the mask
>>>>>>    rw-rw-r-- giving access to it to any other users and allowing group member
>>>>>>    to modify the file - the RPM distribution fixes that by removing the write
>>>>>>    privileges for the group (rw-r--r--). I personnaly don't see the value of
>>>>>>    letting the group members modify those files, I just can see how this could
>>>>>>    be exploited, so I would say it falls into "clearly wrong and not our
>>>>>>    intent". A case might be made for the .properties files, but for jars file
>>>>>>    I really don't see a valid use case (unless of course, any of you know one)
>>>>>>    ;
>>>>>>
>>>>>> There are a few different things here, so let's deal with them
>>>>> separately.
>>>>>
>>>>> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as
>>>>> rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I
>>>>> don't see why they should vary from the general standard. And the
>>>>> module.xml file should be consistent, since there's not much point in
>>>>> locking people from touching jars but letting them change what jars get
>>>>> loaded.
>>>>>
>>>>> For properties files, let's consider them on a more fine-grained
>>>>> basis. For example, the properties files used by the security realms have
>>>>> different kinds of data than logging.properties does.
>>>>>
>>>>> The perms on the security realm property files are rw-------, not
>>>>> rw-rw-r--.
>>>>>
>>>>> The logging.properties files are rw-r--r-- which is consistent with
>>>>> the domain|host|standalone.xml files and with the general standard.
>>>>>
>>>>>
>>>>>>
>>>>>>    -
>>>>>>    - *some directories* like 'domain/tmp/auth' have too restrictive
>>>>>>    mask like rwx------ and RPMS to turned them into rwxrwxr-x (that I don't
>>>>>>    really agree with) and
>>>>>>
>>>>>>
>>>>>>    - *other directories*, likes 'domain' have again a too permissive
>>>>>>    mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make senses.
>>>>>>
>>>>>> In the unzip I see these directories as rwxr-xr-x, which I think is
>>>>> fine.
>>>>>
>>>>> Are you concerned with any other directories besides
>>>>> $JBOSS_HOME/domain and $JBOSS_HOME/standalone?
>>>>>
>>>>>> So we need to find an agreement on those three items, and then see
>>>>>> how we proceed to implement the fix (if needed).
>>>>>>
>>>>>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry <
>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>
>>>>>>> I think we need to start with the assumption that the permissions we
>>>>>>> have in the zip are the way they are for a reason and evaluate possible
>>>>>>> changes based on discussion here of each type of change. Maybe the RPM
>>>>>>> settings are better, maybe they are not. Or maybe they are better but the
>>>>>>> improvement is not worth the disruption a change may cause to our end
>>>>>>> users, who may rely on the current zip settings. Or maybe what we have in
>>>>>>> the zip is clearly wrong and doesn't follow our own intent. I expect we'll
>>>>>>> probably see a little of each category, although hopefully some changes for
>>>>>>> WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :)
>>>>>>>
>>>>>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <belaran at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> As reported on JBEAP-12374[1], there is some discrepancies between
>>>>>>>> the ZIP file we provided for Widlfy/EAP and the RPM generate. Most of those
>>>>>>>> discrepancies - or the most relevant ones, are some fine tuning performed
>>>>>>>> on the (POSIX) privileges (things such as removing the write privilege for
>>>>>>>> member of the same group as the owner of the file).
>>>>>>>>
>>>>>>>> I've looked into this and because those files are produced by our
>>>>>>>> own Maven plugin (as part of wildfly-build-tools), we can not simply modify
>>>>>>>> the assembly.xml. Which actually is probably for the best, as it would made
>>>>>>>> the assembly file quite cumbersome.
>>>>>>>>
>>>>>>>> Anyhow, I've worked on a proposal[2] for the wildfly-build-tools,
>>>>>>>> but when I reported the problem on WFLY-9574[3], Brian suggested I started
>>>>>>>> a discussion here. So does anyone have a (strong) opinion about this issue
>>>>>>>> and/or how to resolve it ? :)
>>>>>>>>
>>>>>>>> (For the record, I do think it is best to fix the privileges to
>>>>>>>> follow what the RPM does for us for now, but if you feel this issue should
>>>>>>>> not be addressed, and dev- the issue, I'm certainly not opposed to it
>>>>>>>> either).
>>>>>>>>
>>>>>>>> [1] https://issues.jboss.org/browse/JBEAP-12374
>>>>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40
>>>>>>>> [3] https://issues.jboss.org/browse/WFLY-9574
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> wildfly-dev mailing list
>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Brian Stansberry
>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>> Red Hat
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Manager, Senior Principal Software Engineer
>>>>> Red Hat
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Manager, Senior Principal Software Engineer
>>>> Red Hat
>>>>
>>>
>>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>>
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171206/cddf9656/attachment-0001.html 

From steve at hibernate.org  Wed Dec  6 06:29:39 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 06 Dec 2017 11:29:39 +0000
Subject: [wildfly-dev] WildFly 11 and JDK9
In-Reply-To: <CAPhbRDYy_-9F6vBYngFcJqZhypDpBDkh9NFHBTxBcQSzg9wRqA@mail.gmail.com>
References: <CAMquZP4-aXwQnM-BaFnF699MPONs6FMetOZYOyeKWAqvrxMUQQ@mail.gmail.com>
	<70A2E4B2-B786-4B32-8A1F-2E5D75803649@redhat.com>
	<CAFdSV9spb5BzSnZBPDdewOxxg62RfbjirmmqaST68wVqUYiGSg@mail.gmail.com>
	<CAPhbRDYy_-9F6vBYngFcJqZhypDpBDkh9NFHBTxBcQSzg9wRqA@mail.gmail.com>
Message-ID: <CAFdSV9szahbY5tUXQZbYpdMTfy5orF=WJN_uSkf+aHZ10_eYYw@mail.gmail.com>

If y'all are willing to pull in Hibernate 5.3 the plan is to switch
Hibernate to use ByteBuddy as It's default provider for byte code
enhancement services rather than Javassist.

5.3 however is our JPA 2.2 (ee8) work, so that has to be factored into the
decision. 2.2 adds some new classes that we do rely on code-wise -
@TableGenerators and @SequenceGenerators.  Because of this we cannot simply
use 5.3 "under" the JPA 2.1 jar

On Tue, Dec 5, 2017, 7:22 PM Brian Stansberry <brian.stansberry at redhat.com>
wrote:

> There's a Javassist 3.22.0-GA out and we've moved on to WF 12 work. What
> are we going to do about this one?
>
> We don't expect a long dev cycle for WF 12 so if we are going to make this
> change we shouldn't delay long. We don't want to try it and see right
> before the release.
>
> On Thu, Aug 31, 2017 at 10:24 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I guess we'd have to TIAS.  Generally history tells us that these
>> Javassist updates do not go smoothly for Hibernate/WF.  However, at least
>> part of purpose of this 3.22 release was for Hibernate and Java 9:
>> https://issues.jboss.org/browse/JASSIST-261
>>
>> Back then I was able to use those 3.22 snapshots successfully, so
>> hopefully this upgrade should go smoothly.  But I agree that I would feel
>> more comfortable with a Final rather than a CR.
>>
>>
>> On Thu, Aug 31, 2017 at 10:14 AM Jason Greene <jason.greene at redhat.com>
>> wrote:
>>
>>> I think its probably too late, but I think we can follow up with an 11.1
>>> or 11.0.1 that includes Java 9 fixes.
>>>
>>> I suspect we probably won?t have everything even if we did update
>>> Javassist (still some test failures etc).
>>>
>>> If someone has a strong argument otherwise, speak now or forever hold
>>> your peace!
>>>
>>> On Aug 31, 2017, at 8:21 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>>>
>>> Hey guys,
>>>
>>> during development of WF11 we have done lots of work on making it build
>>> & run on JDK9.
>>> as release nears I would like to summarize what the current state is and
>>> how to move on.
>>>
>>> Currently most of our core [1] & full [2] testsuite passes on latest
>>> builds of JDK9.
>>> Remaining failures are already addressed by [3] and [4]
>>>
>>> **But** passing testsuite on JDK9 is not the same as using our binary
>>> distribution under JDK9.
>>>
>>> Currently as part of running build / testsuite we override version of
>>> javassit to 3.22.0-CR2
>>> which is currently the only version that works properly on JDK9.
>>> As there is no .GA version of javassit that work on JDK9 avalible we
>>> currently do not have it as default.
>>>
>>> On top of that, hibernate as main user of javassit is not tested enough
>>> with this version of javassist
>>> unless hibernate / JPA team says otherwise.
>>>
>>> That would in practice mean that users running WF11 on JDK9 would have
>>> issues with JPA/Hibernate
>>> based applications.
>>>
>>> Currently I see two options how to address this:
>>> - upgrade javassist to 3.22.x in server, preferably ask for .GA release.
>>> - produce additional WildFly.x.x.x-jdk9 zip that would include the newer
>>> javassist.
>>>
>>> So question is do we even want to have working JDK9 build of WildFly 11
>>> .Final
>>> or should we postpone this for next update release.
>>>
>>> --
>>> tomaz
>>>
>>>
>>> [1]
>>> https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9
>>> [2]
>>> https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea
>>> [3] https://github.com/wildfly/wildfly-core/pull/2738
>>> [4] https://github.com/wildfly/wildfly-core/pull/2751
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>> --
>>> Jason T. Greene
>>> Chief Architect, JBoss EAP
>>> Red Hat
>>>
>>> _______________________________________________
>>> 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
> Manager, Senior Principal Software Engineer
> Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171206/c2f2fe65/attachment.html 

From ropalka at redhat.com  Wed Dec  6 06:32:02 2017
From: ropalka at redhat.com (Richard Opalka)
Date: Wed, 6 Dec 2017 12:32:02 +0100
Subject: [wildfly-dev] Java 9, JBoss Modules, JAXP Redirection
In-Reply-To: <CANghgrS=QWkt6rWt-EJZiWbh27xUFuu1gutT9b_LTPofSVCeFA@mail.gmail.com>
References: <CANghgrS=QWkt6rWt-EJZiWbh27xUFuu1gutT9b_LTPofSVCeFA@mail.gmail.com>
Message-ID: <CABSyOEE_em7zznSGaYESv-7dL0r+yUKTeu+yDGjg7f2Y67ZEXQ@mail.gmail.com>

Hello All,

   Yes, I have different opinion on this topic.

Options 1 and 3 are both introducing some
kind of magic into the JAXP usage picture.

Option 2 puts responsibilities where they
should be.

Since we should not predict JAXP API
users are incompetent I prefer Option 2.

Rio

On Tue, Dec 5, 2017 at 5:10 PM, David Lloyd <david.lloyd at redhat.com> wrote:

>
> Option 1: Fix the redirection facility in Java 9
>
> Option 2: Stop using redirection in Java 9, "cold turkey"
>
> Option 3: Use a dependency strategy
>


> So far Option 1 is (unfortunately) still looking the best to me,
> overall.  Does anyone have any differing opinions on this?
>
> --
> - DML
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev




-- 
--
Richard Opalka
Principal Software Engineer
Red Hat JBoss Middleware
Mobile: +420 731 186 942
E-mail: ropalka at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171206/7fca3ad3/attachment.html 

From kkhan at redhat.com  Wed Dec  6 06:36:58 2017
From: kkhan at redhat.com (Kabir Khan)
Date: Wed, 6 Dec 2017 11:36:58 +0000
Subject: [wildfly-dev] Jirban board for WFLY feature requests/Jira cleanup
Message-ID: <E32E2A57-9946-4962-AA12-FD9944A0F47E@redhat.com>

I have set up a Jirban board for WFLY, which can be found at [1] (log into issues.jboss.org first). It effectively uses the following JQL:

	project = WFLY and status != Closed and issuetype = "Feature Request" and (level is EMPTY and "Security Sensitive Issue" is EMPTY)

As you can see, it currently displays only feature requests.

However, if I organise this into swimlanes by fix version [2] it seems that there a lot of issues in the Resolved state for old releases. 

I think these resolved issues should be closed. Firstly, I believe this is 'The Jira Way'. Secondly, it keeps the Jirban cache of issues on the server as small as possible, as the issues in the states configured to be 'done' in the Jirban config (i.e. Closed) are not cached. Also, the list of Fix Versions in the Jirban filters is populated from the issue data, so a nice side effect will be to keep that list more manageable. At the moment there are too many versions in there to make much sense out of it.

[3] contains a query for all issues in released versions. Here ' 10.x.x TBD' is a bit strange, but I assume these must have been released as part of something by now?

Then we have a few with Fix Version 'Awaiting Volunteers': [4] 

There is a very mysterious Fix Version 'No Release': [5]

Then we have many resolved issues with no fix version but which have been done [6]

Finally we have a load of unresolved issues with no fix version which are rejected, duplicates, out of date etc. [7]

If my queries seem ok, I'd like to bulk close all of these. The ones from [4], [5] and [6] need a bit of care, but hopefully the date they were resolved can help figure out which release they went into. Or perhaps since they have been resolved with a strange fix version for so long, it doesn't matter if they are closed against that version either?

Thanks,

Kabir



[1] https://issues.jboss.org/jirban/index.html#/board?board=WFLY
[2] https://issues.jboss.org/jirban/index.html#/board?board=WFLY-fr&bl=true&swimlane=fix-version
[3] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%20in%20(10.0.0.Alpha1%2C%20%2010.0.0.Alpha2%2C%20%2010.0.0.Alpha3%2C%2010.0.0.Alpha4%2C%2010.0.0.Alpha5%2C%2010.0.0.Alpha6%2C%2010.0.0.Beta1%2C%2010.0.0.Beta2%2C%2010.0.0.CR1%2C%2010.0.0.CR2%2C%20%2010.0.0.CR3%2C%20%2010.0.0.CR4%2C%2010.0.0.CR5%2C%2010.0.0.Final%2C%2010.1.0.CR1%2C%2010.1.0.Final%2C%20%2710.x.x%20TBD%27%2C%20%2011.0.0.Alpha1%2C%20%2011.0.0.Beta1%2C%20%2011.0.0.CR1%2C%20%2011.0.0.Final%2C%20%20%208.0.0.Alpha1%2C%20%208.0.0.Alpha2%2C%20%208.0.0.Alpha3%2C%20%208.0.0.Alpha4%2C%20%208.0.0.Beta1%2C%208.0.0.CR1%2C%20%208.0.0.Final%2C%208.1.0.CR1%2C%20%208.1.0.CR2%2C%20%208.1.0.Final%2C%20%208.2.0.Final%2C%20%209.0.0.Alpha1%2C%20%209.0.0.Beta1%2C%20%209.0.0.Beta2%2C%20%209.0.0.CR1%2C%20%209.0.0.CR2%2C%20%209.0.0.Final%2C%20%209.0.1.Final%2C%20%20%27JBoss%20AS7%207.1.1.Final%27)%0A
[4] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%20in%20(%22Awaiting%20Volunteers%22)%0A
[5] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%20in%20(%22No%20Release%22)%0A
[6] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%20is%20EMPTY%20and%20resolution%20in%20(Done%2C%20%22Resolved%20at%20Apache%22)
[7] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%20is%20EMPTY%20and%20resolution%20not%20in%20(Done%2C%20%22Resolved%20at%20Apache%22)

From kkhan at redhat.com  Wed Dec  6 07:05:06 2017
From: kkhan at redhat.com (Kabir Khan)
Date: Wed, 6 Dec 2017 12:05:06 +0000
Subject: [wildfly-dev] Jirban board for WFLY feature requests/Jira
	cleanup
In-Reply-To: <E32E2A57-9946-4962-AA12-FD9944A0F47E@redhat.com>
References: <E32E2A57-9946-4962-AA12-FD9944A0F47E@redhat.com>
Message-ID: <0875B5B0-D263-496D-A862-4A48868C0903@redhat.com>



> On 6 Dec 2017, at 11:36, Kabir Khan <kkhan at redhat.com> wrote:
> 
> I have set up a Jirban board for WFLY, which can be found at [1] (log into issues.jboss.org first). It effectively uses the following JQL:
> 
> 	project = WFLY and status != Closed and issuetype = "Feature Request" and (level is EMPTY and "Security Sensitive Issue" is EMPTY)
> 
> As you can see, it currently displays only feature requests.
> 
> However, if I organise this into swimlanes by fix version [2] it seems that there a lot of issues in the Resolved state for old releases. 
> 
> I think these resolved issues should be closed. Firstly, I believe this is 'The Jira Way'. Secondly, it keeps the Jirban cache of issues on the server as small as possible, as the issues in the states configured to be 'done' in the Jirban config (i.e. Closed) are not cached. Also, the list of Fix Versions in the Jirban filters is populated from the issue data, so a nice side effect will be to keep that list more manageable. At the moment there are too many versions in there to make much sense out of it.
> 
> [3] contains a query for all issues in released versions. Here ' 10.x.x TBD' is a bit strange, but I assume these must have been released as part of something by now?
> 
> Then we have a few with Fix Version 'Awaiting Volunteers': [4] 
> 
> There is a very mysterious Fix Version 'No Release': [5]
> 
> Then we have many resolved issues with no fix version but which have been done [6]
> 
> Finally we have a load of unresolved issues with no fix version which are rejected, duplicates, out of date etc. [7]
> 
> If my queries seem ok, I'd like to bulk close all of these. The ones from [4], [5] and [6] need a bit of care, but hopefully the date they were resolved can help figure out which release they went into. Or perhaps since they have been resolved with a strange fix version for so long, it doesn't matter if they are closed against that version either?
> 
> Thanks,
> 
> Kabir
> 
> 
> 
> [1] https://issues.jboss.org/jirban/index.html#/board?board=WFLY
[1] should have been https://issues.jboss.org/jirban/index.html#/board?board=WFLY-fr
> 
> [2] https://issues.jboss.org/jirban/index.html#/board?board=WFLY-fr&bl=true&swimlane=fix-version
> [3] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%20in%20(10.0.0.Alpha1%2C%20%2010.0.0.Alpha2%2C%20%2010.0.0.Alpha3%2C%2010.0.0.Alpha4%2C%2010.0.0.Alpha5%2C%2010.0.0.Alpha6%2C%2010.0.0.Beta1%2C%2010.0.0.Beta2%2C%2010.0.0.CR1%2C%2010.0.0.CR2%2C%20%2010.0.0.CR3%2C%20%2010.0.0.CR4%2C%2010.0.0.CR5%2C%2010.0.0.Final%2C%2010.1.0.CR1%2C%2010.1.0.Final%2C%20%2710.x.x%20TBD%27%2C%20%2011.0.0.Alpha1%2C%20%2011.0.0.Beta1%2C%20%2011.0.0.CR1%2C%20%2011.0.0.Final%2C%20%20%208.0.0.Alpha1%2C%20%208.0.0.Alpha2%2C%20%208.0.0.Alpha3%2C%20%208.0.0.Alpha4%2C%20%208.0.0.Beta1%2C%208.0.0.CR1%2C%20%208.0.0.Final%2C%208.1.0.CR1%2C%20%208.1.0.CR2%2C%20%208.1.0.Final%2C%20%208.2.0.Final%2C%20%209.0.0.Alpha1%2C%20%209.0.0.Beta1%2C%20%209.0.0.Beta2%2C%20%209.0.0.CR1%2C%20%209.0.0.CR2%2C%20%209.0.0.Final%2C%20%209.0.1.Final%2C%20%20%27JBoss%20AS7%207.1.1.Final%27)%0A
> [4] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%20in%20(%22Awaiting%20Volunteers%22)%0A
> [5] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%20in%20(%22No%20Release%22)%0A
> [6] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%20is%20EMPTY%20and%20resolution%20in%20(Done%2C%20%22Resolved%20at%20Apache%22)
> [7] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%20is%20EMPTY%20and%20resolution%20not%20in%20(Done%2C%20%22Resolved%20at%20Apache%22)



From rsvoboda at redhat.com  Wed Dec  6 07:31:05 2017
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Wed, 6 Dec 2017 07:31:05 -0500 (EST)
Subject: [wildfly-dev] Policies for merging PRs on master
In-Reply-To: <CAPhbRDaAVT5RPuY1bd1+Ayi3rYaJGWDuotkiFTGo5vCLEgz4Jg@mail.gmail.com>
References: <CAKQecn95fhbz4w7SMBoc+QvSCbcyJ=7MsK_2V3QOqU-2Ja5xrQ@mail.gmail.com>
	<CANghgrRT+qD351=s0cNP24Rjz5ny9Ys8Axy3K-chbxQ8d+iPuw@mail.gmail.com>
	<CAKQecn-UrxaYG=Q-ELYLqDti0vcRzY-LwYCicbV600xqnUuULg@mail.gmail.com>
	<CAPhbRDY7rsynXLy1HR0+Cg5JLS_+CVBx3G+4QNuWXpW6aW2BfA@mail.gmail.com>
	<CAAoo=c6kTt9j-8moNkR1aDML0Mz88j0_y3x7G6Jwj_ctM_jncQ@mail.gmail.com>
	<1bdbcb2e-2a87-3218-b7ba-01728d7d2596@redhat.com>
	<CAPhbRDaAVT5RPuY1bd1+Ayi3rYaJGWDuotkiFTGo5vCLEgz4Jg@mail.gmail.com>
Message-ID: <866285154.53034215.1512563465107.JavaMail.zimbra@redhat.com>

I see 3 main use-cases for TCK runs outside WFLY master

 a) pre-checks before final merging to WFLY master - master-ignore way discussed here
 b) checks on big feature(s) development branches
      something like ladybird or RFE development across multiple components
      selected TCK modules can be executed, depends on scope of changes
 c) regular component checks on component master
      early / regression checks on component level that they do not regress
      TCK modules related to the component and layered components should be executed
      I know only few components which run related TCK modules with their master

With proposed changes for quick WF delivery I believe use-cases b) and c) will need to be addressed.

Use-cases b) and c) could be done on component level or via central pipeline.
  component level - prepare automated way to run TCK with custom build - e.g. bash script, docker image
  central pipeline - set of jobs can be prepared and linked via Jenkins pipeline so the end user (or curl request) provides just URL of custom WFLY build zip + list of modules to be executed

Rostislav

----- Original Message -----
> On Tue, Dec 5, 2017 at 4:37 AM, Scott Marlow < smarlow at redhat.com > wrote:
> 
> 
> It would be great if we could have a branch that includes all of the commits
> that we are considering to merge at a particular time of day, such that we
> would run the TCK against that branch, only once a day.
> 
> Can this be done that often? I had in my mind that if we did one of these it
> would amount to stealing one of the regular runs, but perhaps that's not the
> case.
> 
> Now, I don't think we'd want to do these anywhere near that often, but it's
> good to know what the limits would be. For example, I could imagine doing 10
> of these over the course of a WF release, but by luck or whatever 3 of them
> come in the same week.
> 
> +1 to using a branch. We have a branch like that, master-ignore, that we use
> for batching up PRs to test as a group before merging. I wouldn't want to
> use master-ignore for this, but a differently named branch run the same way
> sounds good.
> 
> 
> 
> If one of the changes cause a TCK failure, none of them get merged
> (investigation follows that to determine which change caused the
> failure(s)), if the test succeeds, we can then merge that batch of changes
> into WildFly master.
> 
> We likely would want to avoid running the testing, on days when we haven't
> merged any changes to the WF testing branching.
> 
> 
> Can the TCK be set up to run based on a check for a change in the sha of the
> head of a branch? So every day at a fixed time it checks the branch, and
> does nothing if there is no change. If we want a run, we force push the
> branch before that time. We have CI jobs that check master-ignore that way,
> except they poll regularly, not just once a day. That works for those as
> they aren't so resource intensive that we worry a lot about limiting how
> often they run.
> 
> 
> Would that approach help how we merge PRs on master?
> 
> 
> I think it could be helpful earlier in the release cycle before merging big
> changes, and then perhaps late in the release cycle if we're worried about
> possible regressions.
> 
> 
> 
> Scott
> 
> On 12/04/2017 09:33 PM, Stuart Douglas wrote:
> 
> 
> 
> 
> On Tue, Dec 5, 2017 at 3:40 AM, Brian Stansberry <
> brian.stansberry at redhat.com <mailto: brian.stansberry at redhat.com >> wrote:
> 
> Great. :)
> 
> One thing I think we need to do is figure out how to get custom TCK
> runs for PR branches. The TCK is a big part of our test coverage,
> and one way to not "use master as a test bed" is to get a check of a
> branch on the TCK before we merge it.
> 
> I know we've gotten TCK runs of ad-hoc branches before, so by
> "figure out" I mean work out how to make that not overly painful,
> come to some sort of consensus on when it's worthwhile, etc.
> 
> 
> I think if we were going to do this it should probably be something reviewers
> can ask for on specific PR. The TCK uses a *lot* more resources than a
> standard CI run, so we need to make sure we limit it to cases where it is
> required.
> 
> Stuart
> 
> 
> On Fri, Dec 1, 2017 at 10:04 AM, Alessio Soldano
> < asoldano at redhat.com <mailto: asoldano at redhat.com >> wrote:
> 
> There you go... PR updated to consume the same api jar now
> released as final.
> 
> Cheers
> Alessio
> 
> On Fri, Dec 1, 2017 at 3:30 PM, David Lloyd
> < david.lloyd at redhat.com <mailto: david.lloyd at redhat.com >> wrote:
> 
> On Thu, Nov 30, 2017 at 5:50 PM, Alessio Soldano
> < asoldano at redhat.com <mailto: asoldano at redhat.com >> wrote:
> > As suggested by Brian, I'd like to draw attention to the discussion on
> > https://github.com/wildfly/wildfly/pull/10604
> < https://github.com/wildfly/wildfly/pull/10604 > .
> > The PR is an upgrade of the webservices stack, including JBossWS, Apache
> > CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade is for EE8 and
> > better JDK 9 compatibility.
> > Now, due to the upgrade of the JAXB API spec jar, the PR is essentially
> > stalled since 20 days; the new spec is released as an alpha (as it's been
> > tested within JBossWS only) and that does not satisfy a rule that requires
> > any artifact being pulled to be Final.
> > We're talking about a spec jar, we could simply re-tag that as Final,
> > chances are we won't need changes any time soon there anyway, but as Tomaz
> > pointed out, in principle that would be dishonest.
> 
> My opinion is that you should go ahead and make a .Final
> tag. In the
> (unlikely?) event that the spec has to be modified for some
> reason, I
> think you could make a 1.0.1.Final tag and call it a "bug fix".
> 
> The alternative is to simply wait. I don't think there is
> any middle position.
> 
> > While I see the point in requiring that only sufficiently stable upgrades
> > are applied to the codebase, I'm wondering whether, maybe, we're going a
> > bit
> > too far with the rules. Brian wrote on this topic: "how to determine that
> > something is good enough to go in without using master as a test bed" ?
> 
> I don't think we are; I agree with the policy as it stands. If you
> look at it in terms of being able to release at any time,
> then it
> follows that everything _must_ be stable.
> 
> --
> - DML
> 
> 
> 
> _______________________________________________
> 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
> < https://lists.jboss.org/mailman/listinfo/wildfly-dev >
> 
> 
> 
> 
> -- Brian Stansberry
> Manager, Senior Principal Software Engineer
> 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
> < 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
> Manager, Senior Principal Software Engineer
> 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 Dec  6 08:52:51 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 6 Dec 2017 07:52:51 -0600
Subject: [wildfly-dev] Jirban board for WFLY feature requests/Jira
	cleanup
In-Reply-To: <0875B5B0-D263-496D-A862-4A48868C0903@redhat.com>
References: <E32E2A57-9946-4962-AA12-FD9944A0F47E@redhat.com>
	<0875B5B0-D263-496D-A862-4A48868C0903@redhat.com>
Message-ID: <CAPhbRDbYDGY==cxADvC-SLD3H6KS2CBb=E179DjDhkpiW8_-zA@mail.gmail.com>

Closing issues after the .Final release is done sounds fine to me. We leave
them Resolved until the .Final release is done because if something comes
up and we need further work it's more of a pain to deal with a closed
issue. But once the .Final release is done, I actually want it to be a pain
to change the issue; e.g. reopening it because someone wants something more
is usually wrong.

10.x.x.TBD is the name of the "next release from the 10.x branch that we
don't have any real plan to ever do, but we have the 10.x branch anyway
just in case so here's a version to track activity on it" version. So
things merged to 10.x since the last release have that version.

Re: "No Release" that's sometimes used for things that aren't really in the
software or something versioned with the software and thus aren't in the
release per se. Some of the stuff in that query looks like that; others
just look like mistakes.


On Wed, Dec 6, 2017 at 6:05 AM, Kabir Khan <kkhan at redhat.com> wrote:

>
>
> > On 6 Dec 2017, at 11:36, Kabir Khan <kkhan at redhat.com> wrote:
> >
> > I have set up a Jirban board for WFLY, which can be found at [1] (log
> into issues.jboss.org first). It effectively uses the following JQL:
> >
> >       project = WFLY and status != Closed and issuetype = "Feature
> Request" and (level is EMPTY and "Security Sensitive Issue" is EMPTY)
> >
> > As you can see, it currently displays only feature requests.
> >
> > However, if I organise this into swimlanes by fix version [2] it seems
> that there a lot of issues in the Resolved state for old releases.
> >
> > I think these resolved issues should be closed. Firstly, I believe this
> is 'The Jira Way'. Secondly, it keeps the Jirban cache of issues on the
> server as small as possible, as the issues in the states configured to be
> 'done' in the Jirban config (i.e. Closed) are not cached. Also, the list of
> Fix Versions in the Jirban filters is populated from the issue data, so a
> nice side effect will be to keep that list more manageable. At the moment
> there are too many versions in there to make much sense out of it.
> >
> > [3] contains a query for all issues in released versions. Here ' 10.x.x
> TBD' is a bit strange, but I assume these must have been released as part
> of something by now?
> >
> > Then we have a few with Fix Version 'Awaiting Volunteers': [4]
> >
> > There is a very mysterious Fix Version 'No Release': [5]
> >
> > Then we have many resolved issues with no fix version but which have
> been done [6]
> >
> > Finally we have a load of unresolved issues with no fix version which
> are rejected, duplicates, out of date etc. [7]
> >
> > If my queries seem ok, I'd like to bulk close all of these. The ones
> from [4], [5] and [6] need a bit of care, but hopefully the date they were
> resolved can help figure out which release they went into. Or perhaps since
> they have been resolved with a strange fix version for so long, it doesn't
> matter if they are closed against that version either?
> >
> > Thanks,
> >
> > Kabir
> >
> >
> >
> > [1] https://issues.jboss.org/jirban/index.html#/board?board=WFLY
> [1] should have been https://issues.jboss.org/jirban/index.html#/board?
> board=WFLY-fr
> >
> > [2] https://issues.jboss.org/jirban/index.html#/board?
> board=WFLY-fr&bl=true&swimlane=fix-version
> > [3] https://issues.jboss.org/issues/?jql=project%20%3D%
> 20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%
> 20in%20(10.0.0.Alpha1%2C%20%2010.0.0.Alpha2%2C%20%2010.0.
> 0.Alpha3%2C%2010.0.0.Alpha4%2C%2010.0.0.Alpha5%2C%2010.0.
> 0.Alpha6%2C%2010.0.0.Beta1%2C%2010.0.0.Beta2%2C%2010.0.0.
> CR1%2C%2010.0.0.CR2%2C%20%2010.0.0.CR3%2C%20%2010.0.0.
> CR4%2C%2010.0.0.CR5%2C%2010.0.0.Final%2C%2010.1.0.CR1%2C%
> 2010.1.0.Final%2C%20%2710.x.x%20TBD%27%2C%20%2011.0.0.
> Alpha1%2C%20%2011.0.0.Beta1%2C%20%2011.0.0.CR1%2C%20%2011.
> 0.0.Final%2C%20%20%208.0.0.Alpha1%2C%20%208.0.0.Alpha2%
> 2C%20%208.0.0.Alpha3%2C%20%208.0.0.Alpha4%2C%20%208.0.0.
> Beta1%2C%208.0.0.CR1%2C%20%208.0.0.Final%2C%208.1.0.CR1%
> 2C%20%208.1.0.CR2%2C%20%208.1.0.Final%2C%20%208.2.0.Final%
> 2C%20%209.0.0.Alpha1%2C%20%209.0.0.Beta1%2C%20%209.0.0.
> Beta2%2C%20%209.0.0.CR1%2C%20%209.0.0.CR2%2C%20%209.0.0.
> Final%2C%20%209.0.1.Final%2C%20%20%27JBoss%20AS7%207.1.1.Final%27)%0A
> > [4] https://issues.jboss.org/issues/?jql=project%20%3D%
> 20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%
> 20in%20(%22Awaiting%20Volunteers%22)%0A
> > [5] https://issues.jboss.org/issues/?jql=project%20%3D%
> 20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%
> 20in%20(%22No%20Release%22)%0A
> > [6] https://issues.jboss.org/issues/?jql=project%20%3D%
> 20WFLY%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%
> 20is%20EMPTY%20and%20resolution%20in%20(Done%2C%
> 20%22Resolved%20at%20Apache%22)
> > [7] https://issues.jboss.org/issues/?jql=project%20%3D%
> 20WFLY%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%
> 20is%20EMPTY%20and%20resolution%20not%20in%20(Done%2C%20%22Resolved%20at%
> 20Apache%22)
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171206/423a0acb/attachment.html 

From tomaz.cerar at gmail.com  Wed Dec  6 10:01:54 2017
From: tomaz.cerar at gmail.com (=?utf-8?Q?Toma=C5=BE_Cerar?=)
Date: Wed, 6 Dec 2017 16:01:54 +0100
Subject: [wildfly-dev] WildFly 11 and JDK9
In-Reply-To: <CAFdSV9szahbY5tUXQZbYpdMTfy5orF=WJN_uSkf+aHZ10_eYYw@mail.gmail.com>
References: <CAMquZP4-aXwQnM-BaFnF699MPONs6FMetOZYOyeKWAqvrxMUQQ@mail.gmail.com>
	<70A2E4B2-B786-4B32-8A1F-2E5D75803649@redhat.com>
	<CAFdSV9spb5BzSnZBPDdewOxxg62RfbjirmmqaST68wVqUYiGSg@mail.gmail.com>
	<CAPhbRDYy_-9F6vBYngFcJqZhypDpBDkh9NFHBTxBcQSzg9wRqA@mail.gmail.com>
	<CAFdSV9szahbY5tUXQZbYpdMTfy5orF=WJN_uSkf+aHZ10_eYYw@mail.gmail.com>
Message-ID: <5a280662.424a1c0a.c2712.4002@mx.google.com>

If hibernate 5.3 is ready and JPA 2.2 passes TCK, than we could probably bring it in.
Aa we do want to add more and more EE8 features, but only if they are ready.

So if you feel that JPA 2.2 impl is ready than please go ahead and send PR for upgrade to 5.3 (given all other conditions for merging are met).

But if you think you cannot get it done in about a month(more or less)  than it would need to be postponed for WF13.
And we need to consider what to do to make WF12 JPA impl work work on JDK9, aka upgrade the javasssit.

--
tomaz

From: Steve Ebersole
Sent: sreda, 06. december 2017 12:29
To: Brian Stansberry
Cc: Jason Greene; Toma? Cerar; wildfly-dev at lists.jboss.org
Subject: Re: [wildfly-dev] WildFly 11 and JDK9

If y'all are willing to pull in Hibernate 5.3 the plan is to switch Hibernate to use ByteBuddy as It's default provider for byte code enhancement services rather than Javassist.? 
5.3 however is our JPA 2.2 (ee8) work, so that has to be factored into the decision. 2.2 adds some new classes that we do rely on code-wise - @TableGenerators and @SequenceGenerators.? Because of this we cannot simply use 5.3 "under" the JPA 2.1 jar

On Tue, Dec 5, 2017, 7:22 PM Brian Stansberry <brian.stansberry at redhat.com> wrote:
There's a Javassist 3.22.0-GA out and we've moved on to WF 12 work. What are we going to do about this one?

We don't expect a long dev cycle for WF 12 so if we are going to make this change we shouldn't delay long. We don't want to try it and see right before the release.?

On Thu, Aug 31, 2017 at 10:24 AM, Steve Ebersole <steve at hibernate.org> wrote:
I guess we'd have to TIAS.? Generally history tells us that these Javassist updates do not go smoothly for Hibernate/WF.? However, at least part of purpose of this 3.22 release was for Hibernate and Java 9:?https://issues.jboss.org/browse/JASSIST-261

Back then I was able to use those 3.22 snapshots successfully, so hopefully this upgrade should go smoothly.? But I agree that I would feel more comfortable with a Final rather than a CR.


On Thu, Aug 31, 2017 at 10:14 AM Jason Greene <jason.greene at redhat.com> wrote:
I think its probably too late, but I think we can follow up with an 11.1 or 11.0.1 that includes Java 9 fixes.?

I suspect we probably won?t have everything even if we did update Javassist (still some test failures etc).

If someone has a strong argument otherwise, speak now or forever hold your peace!

On Aug 31, 2017, at 8:21 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

Hey guys,

during development of WF11 we have done lots of work on making it build & run on JDK9.
as release nears I would like to summarize what the current state is and how to move on.

Currently most of our core [1] & full [2] testsuite passes on latest builds of JDK9.
Remaining failures are already addressed by [3] and [4]

**But** passing testsuite on JDK9 is not the same as using our binary distribution under JDK9.

Currently as part of running build / testsuite we override version of javassit to?3.22.0-CR2
which is currently the only version that works properly on JDK9.
As there is no .GA version of javassit that work on JDK9 avalible we currently do not have it as default.

On top of that, hibernate as main user of javassit is not tested enough with this version of javassist
unless hibernate / JPA team says otherwise.

That would in practice mean that users running WF11 on JDK9 would have issues with JPA/Hibernate?
based applications.

Currently I see two options how to address this:
- upgrade javassist to 3.22.x in server, preferably ask for .GA release.
- produce additional WildFly.x.x.x-jdk9 zip that would include the newer javassist.
?
So question is do we even want to have working JDK9 build of WildFly 11 .Final
or should we postpone this for next update release.

--
tomaz


[1] https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9 
[2]?https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea 
[3]?https://github.com/wildfly/wildfly-core/pull/2738? 
[4]?https://github.com/wildfly/wildfly-core/pull/2751 

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

--
Jason T. Greene
Chief Architect, JBoss EAP
Red Hat

_______________________________________________
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
Manager, Senior Principal Software Engineer
Red Hat

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

From steve at hibernate.org  Wed Dec  6 10:39:50 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 06 Dec 2017 15:39:50 +0000
Subject: [wildfly-dev] WildFly 11 and JDK9
In-Reply-To: <5a280662.424a1c0a.c2712.4002@mx.google.com>
References: <CAMquZP4-aXwQnM-BaFnF699MPONs6FMetOZYOyeKWAqvrxMUQQ@mail.gmail.com>
	<70A2E4B2-B786-4B32-8A1F-2E5D75803649@redhat.com>
	<CAFdSV9spb5BzSnZBPDdewOxxg62RfbjirmmqaST68wVqUYiGSg@mail.gmail.com>
	<CAPhbRDYy_-9F6vBYngFcJqZhypDpBDkh9NFHBTxBcQSzg9wRqA@mail.gmail.com>
	<CAFdSV9szahbY5tUXQZbYpdMTfy5orF=WJN_uSkf+aHZ10_eYYw@mail.gmail.com>
	<5a280662.424a1c0a.c2712.4002@mx.google.com>
Message-ID: <CAFdSV9t-ioC3gL53-=i76=Hi3U=aUoe3th236f5yhf4LwmgvBQ@mail.gmail.com>

At this point we have 2 open bugs that we need to fix.  Unfortunately we
have roughly 28 open challenges with Oracle for bad TCK tests.  The plan is
to release a Beta once the 2 bugs are fixed.  I won't release a Final until
we get the certification from Oracle, which means waiting for all of these
challenges to be resolved.  I don't have to tell anyone here the
"quickness" of getting fixes for these challenges.

So define "ready" :)


On Wed, Dec 6, 2017 at 9:02 AM Toma? Cerar <tomaz.cerar at gmail.com> wrote:

> If hibernate 5.3 is ready and JPA 2.2 passes TCK, than we could probably
> bring it in.
>
> Aa we do want to add more and more EE8 features, but only if they are
> ready.
>
>
>
> So if you feel that JPA 2.2 impl is ready than please go ahead and send PR
> for upgrade to 5.3 (given all other conditions for merging are met).
>
>
>
> But if you think you cannot get it done in about a month(more or less)
>  than it would need to be postponed for WF13.
>
> And we need to consider what to do to make WF12 JPA impl work work on
> JDK9, aka upgrade the javasssit.
>
>
>
> --
>
> tomaz
>
>
>
> *From: *Steve Ebersole <steve at hibernate.org>
> *Sent: *sreda, 06. december 2017 12:29
> *To: *Brian Stansberry <brian.stansberry at redhat.com>
> *Cc: *Jason Greene <jason.greene at redhat.com>; Toma? Cerar
> <tomaz.cerar at gmail.com>; wildfly-dev at lists.jboss.org
> *Subject: *Re: [wildfly-dev] WildFly 11 and JDK9
>
>
>
> If y'all are willing to pull in Hibernate 5.3 the plan is to switch
> Hibernate to use ByteBuddy as It's default provider for byte code
> enhancement services rather than Javassist.
>
> 5.3 however is our JPA 2.2 (ee8) work, so that has to be factored into the
> decision. 2.2 adds some new classes that we do rely on code-wise -
> @TableGenerators and @SequenceGenerators.  Because of this we cannot simply
> use 5.3 "under" the JPA 2.1 jar
>
>
>
> On Tue, Dec 5, 2017, 7:22 PM Brian Stansberry <brian.stansberry at redhat.com>
> wrote:
>
> There's a Javassist 3.22.0-GA out and we've moved on to WF 12 work. What
> are we going to do about this one?
>
>
>
> We don't expect a long dev cycle for WF 12 so if we are going to make this
> change we shouldn't delay long. We don't want to try it and see right
> before the release.
>
>
>
> On Thu, Aug 31, 2017 at 10:24 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> I guess we'd have to TIAS.  Generally history tells us that these
> Javassist updates do not go smoothly for Hibernate/WF.  However, at least
> part of purpose of this 3.22 release was for Hibernate and Java 9:
> https://issues.jboss.org/browse/JASSIST-261
>
>
>
> Back then I was able to use those 3.22 snapshots successfully, so
> hopefully this upgrade should go smoothly.  But I agree that I would feel
> more comfortable with a Final rather than a CR.
>
>
>
>
>
> On Thu, Aug 31, 2017 at 10:14 AM Jason Greene <jason.greene at redhat.com>
> wrote:
>
> I think its probably too late, but I think we can follow up with an 11.1
> or 11.0.1 that includes Java 9 fixes.
>
>
>
> I suspect we probably won?t have everything even if we did update
> Javassist (still some test failures etc).
>
>
>
> If someone has a strong argument otherwise, speak now or forever hold your
> peace!
>
>
>
> On Aug 31, 2017, at 8:21 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
>
>
>
> Hey guys,
>
>
>
> during development of WF11 we have done lots of work on making it build &
> run on JDK9.
>
> as release nears I would like to summarize what the current state is and
> how to move on.
>
>
>
> Currently most of our core [1] & full [2] testsuite passes on latest
> builds of JDK9.
>
> Remaining failures are already addressed by [3] and [4]
>
>
>
> **But** passing testsuite on JDK9 is not the same as using our binary
> distribution under JDK9.
>
>
>
> Currently as part of running build / testsuite we override version of
> javassit to 3.22.0-CR2
>
> which is currently the only version that works properly on JDK9.
>
> As there is no .GA version of javassit that work on JDK9 avalible we
> currently do not have it as default.
>
>
>
> On top of that, hibernate as main user of javassit is not tested enough
> with this version of javassist
>
> unless hibernate / JPA team says otherwise.
>
>
>
> That would in practice mean that users running WF11 on JDK9 would have
> issues with JPA/Hibernate
>
> based applications.
>
>
>
> Currently I see two options how to address this:
>
> - upgrade javassist to 3.22.x in server, preferably ask for .GA release.
>
> - produce additional WildFly.x.x.x-jdk9 zip that would include the newer
> javassist.
>
>
>
> So question is do we even want to have working JDK9 build of WildFly 11
> .Final
>
> or should we postpone this for next update release.
>
>
>
> --
>
> tomaz
>
>
>
>
>
> [1]
> https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9
>
> [2] https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea
>
> [3] https://github.com/wildfly/wildfly-core/pull/2738
>
> [4] https://github.com/wildfly/wildfly-core/pull/2751
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> --
> Jason T. Greene
> Chief Architect, JBoss EAP
>
> Red Hat
>
>
>
> _______________________________________________
> 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
>
> Manager, Senior Principal Software Engineer
>
> Red Hat
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171206/8f72cf34/attachment.html 

From kkhan at redhat.com  Wed Dec  6 11:22:37 2017
From: kkhan at redhat.com (Kabir Khan)
Date: Wed, 6 Dec 2017 16:22:37 +0000
Subject: [wildfly-dev] Jirban board for WFLY feature requests/Jira
	cleanup
In-Reply-To: <CAPhbRDbYDGY==cxADvC-SLD3H6KS2CBb=E179DjDhkpiW8_-zA@mail.gmail.com>
References: <E32E2A57-9946-4962-AA12-FD9944A0F47E@redhat.com>
	<0875B5B0-D263-496D-A862-4A48868C0903@redhat.com>
	<CAPhbRDbYDGY==cxADvC-SLD3H6KS2CBb=E179DjDhkpiW8_-zA@mail.gmail.com>
Message-ID: <2070B1EE-5757-40C4-9E97-2FA90472D0B0@redhat.com>

I am doing the bulk closures. I already had some complaints about the email spam, and there is a lot more to come. So, I will ask Jira not to send notifications for anything from the first set at least ([3] below).

> On 6 Dec 2017, at 13:52, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> Closing issues after the .Final release is done sounds fine to me. We leave them Resolved until the .Final release is done because if something comes up and we need further work it's more of a pain to deal with a closed issue. But once the .Final release is done, I actually want it to be a pain to change the issue; e.g. reopening it because someone wants something more is usually wrong.
> 
> 10.x.x.TBD is the name of the "next release from the 10.x branch that we don't have any real plan to ever do, but we have the 10.x branch anyway just in case so here's a version to track activity on it" version. So things merged to 10.x since the last release have that version.
> 
> Re: "No Release" that's sometimes used for things that aren't really in the software or something versioned with the software and thus aren't in the release per se. Some of the stuff in that query looks like that; others just look like mistakes.
> 
> 
> On Wed, Dec 6, 2017 at 6:05 AM, Kabir Khan <kkhan at redhat.com> wrote:
> 
> 
> > On 6 Dec 2017, at 11:36, Kabir Khan <kkhan at redhat.com> wrote:
> >
> > I have set up a Jirban board for WFLY, which can be found at [1] (log into issues.jboss.org first). It effectively uses the following JQL:
> >
> >       project = WFLY and status != Closed and issuetype = "Feature Request" and (level is EMPTY and "Security Sensitive Issue" is EMPTY)
> >
> > As you can see, it currently displays only feature requests.
> >
> > However, if I organise this into swimlanes by fix version [2] it seems that there a lot of issues in the Resolved state for old releases.
> >
> > I think these resolved issues should be closed. Firstly, I believe this is 'The Jira Way'. Secondly, it keeps the Jirban cache of issues on the server as small as possible, as the issues in the states configured to be 'done' in the Jirban config (i.e. Closed) are not cached. Also, the list of Fix Versions in the Jirban filters is populated from the issue data, so a nice side effect will be to keep that list more manageable. At the moment there are too many versions in there to make much sense out of it.
> >
> > [3] contains a query for all issues in released versions. Here ' 10.x.x TBD' is a bit strange, but I assume these must have been released as part of something by now?
> >
> > Then we have a few with Fix Version 'Awaiting Volunteers': [4]
> >
> > There is a very mysterious Fix Version 'No Release': [5]
> >
> > Then we have many resolved issues with no fix version but which have been done [6]
> >
> > Finally we have a load of unresolved issues with no fix version which are rejected, duplicates, out of date etc. [7]
> >
> > If my queries seem ok, I'd like to bulk close all of these. The ones from [4], [5] and [6] need a bit of care, but hopefully the date they were resolved can help figure out which release they went into. Or perhaps since they have been resolved with a strange fix version for so long, it doesn't matter if they are closed against that version either?
> >
> > Thanks,
> >
> > Kabir
> >
> >
> >
> > [1] https://issues.jboss.org/jirban/index.html#/board?board=WFLY
> [1] should have been https://issues.jboss.org/jirban/index.html#/board?board=WFLY-fr
> >
> > [2] https://issues.jboss.org/jirban/index.html#/board?board=WFLY-fr&bl=true&swimlane=fix-version
> > [3] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%20in%20(10.0.0.Alpha1%2C%20%2010.0.0.Alpha2%2C%20%2010.0.0.Alpha3%2C%2010.0.0.Alpha4%2C%2010.0.0.Alpha5%2C%2010.0.0.Alpha6%2C%2010.0.0.Beta1%2C%2010.0.0.Beta2%2C%2010.0.0.CR1%2C%2010.0.0.CR2%2C%20%2010.0.0.CR3%2C%20%2010.0.0.CR4%2C%2010.0.0.CR5%2C%2010.0.0.Final%2C%2010.1.0.CR1%2C%2010.1.0.Final%2C%20%2710.x.x%20TBD%27%2C%20%2011.0.0.Alpha1%2C%20%2011.0.0.Beta1%2C%20%2011.0.0.CR1%2C%20%2011.0.0.Final%2C%20%20%208.0.0.Alpha1%2C%20%208.0.0.Alpha2%2C%20%208.0.0.Alpha3%2C%20%208.0.0.Alpha4%2C%20%208.0.0.Beta1%2C%208.0.0.CR1%2C%20%208.0.0.Final%2C%208.1.0.CR1%2C%20%208.1.0.CR2%2C%20%208.1.0.Final%2C%20%208.2.0.Final%2C%20%209.0.0.Alpha1%2C%20%209.0.0.Beta1%2C%20%209.0.0.Beta2%2C%20%209.0.0.CR1%2C%20%209.0.0.CR2%2C%20%209.0.0.Final%2C%20%209.0.1.Final%2C%20%20%27JBoss%20AS7%207.1.1.Final%27)%0A
> > [4] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%20in%20(%22Awaiting%20Volunteers%22)%0A
> > [5] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%20in%20(%22No%20Release%22)%0A
> > [6] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%20is%20EMPTY%20and%20resolution%20in%20(Done%2C%20%22Resolved%20at%20Apache%22)
> > [7] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%20is%20EMPTY%20and%20resolution%20not%20in%20(Done%2C%20%22Resolved%20at%20Apache%22)
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> 
> -- 
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat



From tomaz.cerar at gmail.com  Wed Dec  6 11:28:55 2017
From: tomaz.cerar at gmail.com (=?utf-8?Q?Toma=C5=BE_Cerar?=)
Date: Wed, 6 Dec 2017 17:28:55 +0100
Subject: [wildfly-dev] WildFly 11 and JDK9
In-Reply-To: <CAFdSV9t-ioC3gL53-=i76=Hi3U=aUoe3th236f5yhf4LwmgvBQ@mail.gmail.com>
References: <CAMquZP4-aXwQnM-BaFnF699MPONs6FMetOZYOyeKWAqvrxMUQQ@mail.gmail.com>
	<70A2E4B2-B786-4B32-8A1F-2E5D75803649@redhat.com>
	<CAFdSV9spb5BzSnZBPDdewOxxg62RfbjirmmqaST68wVqUYiGSg@mail.gmail.com>
	<CAPhbRDYy_-9F6vBYngFcJqZhypDpBDkh9NFHBTxBcQSzg9wRqA@mail.gmail.com>
	<CAFdSV9szahbY5tUXQZbYpdMTfy5orF=WJN_uSkf+aHZ10_eYYw@mail.gmail.com>
	<5a280662.424a1c0a.c2712.4002@mx.google.com>
	<CAFdSV9t-ioC3gL53-=i76=Hi3U=aUoe3th236f5yhf4LwmgvBQ@mail.gmail.com>
Message-ID: <5a281ac7.51bbdf0a.a2876.367f@mx.google.com>

Ready as in it has .Final version and you are willing to integrate in into WildFly.

Given the state you give, it looks like there is slim chance to get all challenges fixed by time for WF12?

--
tomaz

From: Steve Ebersole
Sent: sreda, 06. december 2017 16:40
To: Toma? Cerar
Cc: Brian Stansberry; Jason Greene; wildfly-dev at lists.jboss.org
Subject: Re: [wildfly-dev] WildFly 11 and JDK9

At this point we have 2 open bugs that we need to fix.? Unfortunately we have roughly 28 open challenges with Oracle for bad TCK tests.? The plan is to release a Beta once the 2 bugs are fixed.? I won't release a Final until we get the certification from Oracle, which means waiting for all of these challenges to be resolved.? I don't have to tell anyone here the "quickness" of getting fixes for these challenges.

So define "ready" :)


On Wed, Dec 6, 2017 at 9:02 AM Toma? Cerar <tomaz.cerar at gmail.com> wrote:
If hibernate 5.3 is ready and JPA 2.2 passes TCK, than we could probably bring it in.
Aa we do want to add more and more EE8 features, but only if they are ready.
?
So if you feel that JPA 2.2 impl is ready than please go ahead and send PR for upgrade to 5.3 (given all other conditions for merging are met).
?
But if you think you cannot get it done in about a month(more or less) ?than it would need to be postponed for WF13.
And we need to consider what to do to make WF12 JPA impl work work on JDK9, aka upgrade the javasssit.
?
--
tomaz
?
From: Steve Ebersole
Sent: sreda, 06. december 2017 12:29
To: Brian Stansberry
Cc: Jason Greene; Toma? Cerar; wildfly-dev at lists.jboss.org
Subject: Re: [wildfly-dev] WildFly 11 and JDK9
?
If y'all are willing to pull in Hibernate 5.3 the plan is to switch Hibernate to use ByteBuddy as It's default provider for byte code enhancement services rather than Javassist.? 
5.3 however is our JPA 2.2 (ee8) work, so that has to be factored into the decision. 2.2 adds some new classes that we do rely on code-wise - @TableGenerators and @SequenceGenerators.? Because of this we cannot simply use 5.3 "under" the JPA 2.1 jar
?
On Tue, Dec 5, 2017, 7:22 PM Brian Stansberry <brian.stansberry at redhat.com> wrote:
There's a Javassist 3.22.0-GA out and we've moved on to WF 12 work. What are we going to do about this one?
?
We don't expect a long dev cycle for WF 12 so if we are going to make this change we shouldn't delay long. We don't want to try it and see right before the release.?
?
On Thu, Aug 31, 2017 at 10:24 AM, Steve Ebersole <steve at hibernate.org> wrote:
I guess we'd have to TIAS.? Generally history tells us that these Javassist updates do not go smoothly for Hibernate/WF.? However, at least part of purpose of this 3.22 release was for Hibernate and Java 9:?https://issues.jboss.org/browse/JASSIST-261
?
Back then I was able to use those 3.22 snapshots successfully, so hopefully this upgrade should go smoothly.? But I agree that I would feel more comfortable with a Final rather than a CR.
?
?
On Thu, Aug 31, 2017 at 10:14 AM Jason Greene <jason.greene at redhat.com> wrote:
I think its probably too late, but I think we can follow up with an 11.1 or 11.0.1 that includes Java 9 fixes.?
?
I suspect we probably won?t have everything even if we did update Javassist (still some test failures etc).
?
If someone has a strong argument otherwise, speak now or forever hold your peace!
?
On Aug 31, 2017, at 8:21 AM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:
?
Hey guys,
?
during development of WF11 we have done lots of work on making it build & run on JDK9.
as release nears I would like to summarize what the current state is and how to move on.
?
Currently most of our core [1] & full [2] testsuite passes on latest builds of JDK9.
Remaining failures are already addressed by [3] and [4]
?
**But** passing testsuite on JDK9 is not the same as using our binary distribution under JDK9.
?
Currently as part of running build / testsuite we override version of javassit to?3.22.0-CR2
which is currently the only version that works properly on JDK9.
As there is no .GA version of javassit that work on JDK9 avalible we currently do not have it as default.
?
On top of that, hibernate as main user of javassit is not tested enough with this version of javassist
unless hibernate / JPA team says otherwise.
?
That would in practice mean that users running WF11 on JDK9 would have issues with JPA/Hibernate?
based applications.
?
Currently I see two options how to address this:
- upgrade javassist to 3.22.x in server, preferably ask for .GA release.
- produce additional WildFly.x.x.x-jdk9 zip that would include the newer javassist.
?
So question is do we even want to have working JDK9 build of WildFly 11 .Final
or should we postpone this for next update release.
?
--
tomaz
?
?
[1] https://ci.wildfly.org/viewType.html?buildTypeId=WildFlyCore_MasterLinuxJdk9 
[2]?https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxJdk9ea 
[3]?https://github.com/wildfly/wildfly-core/pull/2738? 
[4]?https://github.com/wildfly/wildfly-core/pull/2751 
?
_______________________________________________
wildfly-dev mailing list
wildfly-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
?
--
Jason T. Greene
Chief Architect, JBoss EAP
Red Hat
?
_______________________________________________
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
Manager, Senior Principal Software Engineer
Red Hat
?

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

From brian.stansberry at redhat.com  Wed Dec  6 12:05:07 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 6 Dec 2017 11:05:07 -0600
Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have
 POSIX permissions perfectly set
In-Reply-To: <CALuBA_qxu=nGP93yfPXEdhiUdxBkQ2C7YZx=82i7qbOA=egr+A@mail.gmail.com>
References: <CALuBA_p5Mqag2+TSD9bUWGM5BgDpirdZC7zvL5OE8w-HfA4AWw@mail.gmail.com>
	<CAPhbRDYyGwNpqFq8bYdRk53_hx6Mg4yHwOcmmYYnwDp_3-B+_A@mail.gmail.com>
	<CALuBA_pSvfNYPug1byQrS7Bic45vVvvdQ4Mjd-BQ6Pa4t5m05g@mail.gmail.com>
	<CAPhbRDYnYLd-SXuE_m_2b14W9VwNhy08KDpC0MdP6n3mipMi0A@mail.gmail.com>
	<CAPhbRDZFTd52gO8-psaaXJSVNAPn=3MtjA3XuyEC501Hj-rRJw@mail.gmail.com>
	<CALuBA_pXT89PNspojT-sT3GNTVhf1R1F7YJPxn7K-B6dmP4+bg@mail.gmail.com>
	<CAPhbRDZFfcuS5kZNHU99cVDSTjewsVynuaZAAxsxdQSswxOZOA@mail.gmail.com>
	<CAPhbRDYN_PGP8fo6BizQ3EOR-=9UT_jrJEECzLBfT-DoOt05fg@mail.gmail.com>
	<CALuBA_qxu=nGP93yfPXEdhiUdxBkQ2C7YZx=82i7qbOA=egr+A@mail.gmail.com>
Message-ID: <CAPhbRDZAnSLP6OYkWUHkvczj-sm4FGaE6apEEoiGRo_D+Z=nww@mail.gmail.com>

On Wed, Dec 6, 2017 at 4:27 AM, Romain Pelisse <belaran at redhat.com> wrote:

> Hi Brian (and all),
>
> I honestly understand your resistance, and I'm completely fine if we end
> up closing this all issue as WONTDO or REJECTED. I just do want to have a
> discussion about it and come back with clear reasons and motivations for
> changing or not the privileges of each of those files.
>

Thanks for doing this! There have been a number of issues filed over the
last year or so on this general topic so I'm very happy to see them getting
addressed here via the WildFly community. Most of the issues I've been
talking about are JBEAP issues in JIRA, which is fine, but the best way to
get this solid is to get WildFly the way we want it first.

Even on the config file read perms thing I mentioned in my last post, I'm
personally resistant to changing it, but my biggest resistance is to doing
that without a full community discussion.


> Given that we see different things on our local setup, I think the best
> will be to use a build on a CI Server and works from what we see there. Is
> there an easy way for me to clone a job building Wildfly and tweak it on
> some (publicly) accessible instance ?
>

https://developer.jboss.org/thread/224262 describes how to get a zip built
from a daily CI job.

If anyone has any insights on this, please speak up!


>
>
> On Mon, Dec 4, 2017 at 6:48 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>> A slightly different topic, related to the "logging.properties/xml config
>> file" topic is whether these files should be world and/or group readable.
>>
>> Changing this has been proposed in the past on the EAP side, primarily
>> based on the argument that users could put sensitive data in these files.
>> This thread seems like a good time to debate this a bit in community.
>>
>> I've resisted that primarily on the basis of:
>>
>> 1) These files or those similarly used have had these perms as far back
>> as I can find in JBoss AS. So the odds that some people are relying upon
>> those perms is fairly high and we need to assume a change would be a
>> breaking change for some people.
>>
>> 2) Other software I've looked at like Tomcat and httpd have similar
>> permission schemes to what we have for their config files, which can also
>> potentially include sensitive data.
>>
>> 3) We provide facilities like the vault or elytron credential store refs
>> for keeping sensitive data out of the config files.
>>
>>
>> On Mon, Dec 4, 2017 at 11:38 AM, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>>
>>> Thanks, Romain.
>>>
>>> Re: what the actual permissions are, FWIW I get what I see on both my
>>> macbook and my Fedora 27 machine, both when unzipping the actual
>>> 11.0.0.Final and when unzipping the result of a build of master, and both
>>> with and without the -Prelease -Pjboss-release args to maven that we
>>> include when doing actual releases. Unzipping the zip in build/target
>>> doesn't include the jars of course.
>>>
>>> So it sounds like we need input from others.
>>>
>>> Re: modules.xml, if you are seeing those as rw-r--r-- as well, then +1
>>> to ignoring them in further discussion.
>>>
>>> Re: logging.properties, those serve a very similar conceptual role to
>>> the standalone|host|domain.xml files so I see no reason for them to have
>>> different perms. However, you and I are getting different results, where
>>> you report them as group writable and I don't. What do you see for the xml
>>> config files?
>>>
>>> Re: RPM changing to match WildFly, that's an EAP discussion, so that can
>>> be taken up elsewhere once we have WildFly the way we want it.
>>>
>>>
>>> On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse <belaran at redhat.com>
>>> wrote:
>>>
>>>> Hi Brian and all,
>>>>
>>>> err, my own observation differs from yours. I've rebuild Wildfly from
>>>> the last content of the master branch and get the same privileges on the
>>>> jboss-modules.jar (so -rw-rw-r-- and not as you are seeing  rwxr--r--).
>>>> Same with the domain folder, which turns out on my local system associated
>>>> to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a
>>>> transcript of what I did - maybe you can spot why our results differs so
>>>> much.
>>>>
>>>> $ git show
>>>> commit 46e119c65d9e32bc0ec69f3933267fece959ed3f
>>>> Merge: 051f080 c7d9075
>>>> Author: Kabir Khan <kkhan at redhat.com>
>>>> Date:   Tue Nov 28 17:46:40 2017 +0000
>>>>
>>>>     Merge pull request #10669 from praxeo/WFLY-9284
>>>>
>>>>     WFLY-9284 Correct MVN env variable to mvnw.cmd
>>>>
>>>> $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d
>>>> wildfly-12.zip
>>>> ...
>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
>>>> -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov.  11:41
>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/  -d
>>>> drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov.  11:41
>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/
>>>>
>>>> Checking all the jars in the distribution, they all appears to have the
>>>> mask '-rw-rw-r--':
>>>>
>>>> $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done | sed
>>>> -e '/-rw-rw-r--/d'
>>>> $
>>>>
>>>> Regarding properties files, here is the exhaustive list of properties
>>>> that RPM packaging has modified the privileges of:
>>>>
>>>> appclient/configuration/logging.properties rw-------
>>>> domain/configuration/application-roles.properties rw-------
>>>> domain/configuration/default-server-logging.properties rw-------
>>>> domain/configuration/logging.properties rw-------
>>>> domain/configuration/mgmt-groups.properties rw-------
>>>> standalone/configuration/application-roles.properties rw-------
>>>> standalone/configuration/logging.properties rw-------
>>>> standalone/configuration/mgmt-groups.properties rw-------
>>>>
>>>> If I compare that with the content of the extract zip (same fresh built
>>>> as above), I can see that 4 files are not having the same mask (rw------):
>>>>
>>>> $ for file in $(cut -f1 -d\  ../../../list-props-files.txt ); do ls -l
>>>> $file ; done
>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>>> appclient/configuration/logging.properties
>>>> -rw-------. 1 rpelisse rpelisse 710 30 nov.  11:41
>>>> domain/configuration/application-roles.properties
>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>>> domain/configuration/default-server-logging.properties
>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>>> domain/configuration/logging.properties
>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>>> domain/configuration/mgmt-groups.properties
>>>> -rw-------. 1 rpelisse rpelisse 711 30 nov.  11:41
>>>> standalone/configuration/application-roles.properties
>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>>> standalone/configuration/logging.properties
>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>>> standalone/configuration/mgmt-groups.properties
>>>>
>>>> Now, as you said, those files privileges are indeed fine-grained, so
>>>> maybe we can push back to people making the RPM for them to NOT change the
>>>> following files privileges:
>>>>
>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>>> appclient/configuration/logging.properties
>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>>> domain/configuration/default-server-logging.properties
>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>>> domain/configuration/logging.properties
>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>>> standalone/configuration/logging.properties
>>>>
>>>> However, I don't see the value of letting those files accessible either
>>>> group member or any user on the system, but maybe we can make the argument
>>>> they should. But the write privileges for group member sounds wrong to me.
>>>>
>>>> Also, I'm puzzled Brian and I are seeing different things - am I
>>>> looking at the correct zipfile here ?
>>>>
>>>> Note: You also mention the module.xml - as far as I can see from the
>>>> diff provided with issue JBEAP-12374, I don't see any issue with privileges
>>>> regarding those files, so we can remove them of the discussion. The only
>>>> changes we need to discuss is removing the 'write' privileges' for the
>>>> group on jars, reducing the scope of permissions on (some) folders, and
>>>> privileges on (some) properties files. So, module.xml are out of the scope.
>>>>
>>>> On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry <
>>>> brian.stansberry at redhat.com> wrote:
>>>>
>>>>> Seems I forgot to "Reply to All" yesterday. The following was meant to
>>>>> be sent to wildfly-dev.
>>>>>
>>>>> On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry <
>>>>> brian.stansberry at redhat.com> wrote:
>>>>>
>>>>>> Before getting into the specifics, first a general note re: perms.
>>>>>>
>>>>>> Our general permission set for is rwxr-xr-x for directories and
>>>>>> rwxr--r-- for files. If someone thinks that's wrong in general; speak up.
>>>>>> ;). Otherwise I think any deviation from that we should justify. Not that
>>>>>> deviations are wrong, just that they need to have a reason.
>>>>>>
>>>>>> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <belaran at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Well, the diff is between the RPM and the zipfile is pretty long,
>>>>>>> but it boils down to the 3 set of differences I've pointed out on
>>>>>>> WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574>
>>>>>>>
>>>>>>>    - *.properties and .jar* files are associated with the mask
>>>>>>>    rw-rw-r-- giving access to it to any other users and allowing group member
>>>>>>>    to modify the file - the RPM distribution fixes that by removing the write
>>>>>>>    privileges for the group (rw-r--r--). I personnaly don't see the value of
>>>>>>>    letting the group members modify those files, I just can see how this could
>>>>>>>    be exploited, so I would say it falls into "clearly wrong and not our
>>>>>>>    intent". A case might be made for the .properties files, but for jars file
>>>>>>>    I really don't see a valid use case (unless of course, any of you know one)
>>>>>>>    ;
>>>>>>>
>>>>>>> There are a few different things here, so let's deal with them
>>>>>> separately.
>>>>>>
>>>>>> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as
>>>>>> rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I
>>>>>> don't see why they should vary from the general standard. And the
>>>>>> module.xml file should be consistent, since there's not much point in
>>>>>> locking people from touching jars but letting them change what jars get
>>>>>> loaded.
>>>>>>
>>>>>> For properties files, let's consider them on a more fine-grained
>>>>>> basis. For example, the properties files used by the security realms have
>>>>>> different kinds of data than logging.properties does.
>>>>>>
>>>>>> The perms on the security realm property files are rw-------, not
>>>>>> rw-rw-r--.
>>>>>>
>>>>>> The logging.properties files are rw-r--r-- which is consistent with
>>>>>> the domain|host|standalone.xml files and with the general standard.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>    -
>>>>>>>    - *some directories* like 'domain/tmp/auth' have too restrictive
>>>>>>>    mask like rwx------ and RPMS to turned them into rwxrwxr-x (that I don't
>>>>>>>    really agree with) and
>>>>>>>
>>>>>>>
>>>>>>>    - *other directories*, likes 'domain' have again a too
>>>>>>>    permissive mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make
>>>>>>>    senses.
>>>>>>>
>>>>>>> In the unzip I see these directories as rwxr-xr-x, which I think is
>>>>>> fine.
>>>>>>
>>>>>> Are you concerned with any other directories besides
>>>>>> $JBOSS_HOME/domain and $JBOSS_HOME/standalone?
>>>>>>
>>>>>>> So we need to find an agreement on those three items, and then see
>>>>>>> how we proceed to implement the fix (if needed).
>>>>>>>
>>>>>>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry <
>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>
>>>>>>>> I think we need to start with the assumption that the permissions
>>>>>>>> we have in the zip are the way they are for a reason and evaluate possible
>>>>>>>> changes based on discussion here of each type of change. Maybe the RPM
>>>>>>>> settings are better, maybe they are not. Or maybe they are better but the
>>>>>>>> improvement is not worth the disruption a change may cause to our end
>>>>>>>> users, who may rely on the current zip settings. Or maybe what we have in
>>>>>>>> the zip is clearly wrong and doesn't follow our own intent. I expect we'll
>>>>>>>> probably see a little of each category, although hopefully some changes for
>>>>>>>> WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :)
>>>>>>>>
>>>>>>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <belaran at redhat.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> As reported on JBEAP-12374[1], there is some discrepancies between
>>>>>>>>> the ZIP file we provided for Widlfy/EAP and the RPM generate. Most of those
>>>>>>>>> discrepancies - or the most relevant ones, are some fine tuning performed
>>>>>>>>> on the (POSIX) privileges (things such as removing the write privilege for
>>>>>>>>> member of the same group as the owner of the file).
>>>>>>>>>
>>>>>>>>> I've looked into this and because those files are produced by our
>>>>>>>>> own Maven plugin (as part of wildfly-build-tools), we can not simply modify
>>>>>>>>> the assembly.xml. Which actually is probably for the best, as it would made
>>>>>>>>> the assembly file quite cumbersome.
>>>>>>>>>
>>>>>>>>> Anyhow, I've worked on a proposal[2] for the wildfly-build-tools,
>>>>>>>>> but when I reported the problem on WFLY-9574[3], Brian suggested I started
>>>>>>>>> a discussion here. So does anyone have a (strong) opinion about this issue
>>>>>>>>> and/or how to resolve it ? :)
>>>>>>>>>
>>>>>>>>> (For the record, I do think it is best to fix the privileges to
>>>>>>>>> follow what the RPM does for us for now, but if you feel this issue should
>>>>>>>>> not be addressed, and dev- the issue, I'm certainly not opposed to it
>>>>>>>>> either).
>>>>>>>>>
>>>>>>>>> [1] https://issues.jboss.org/browse/JBEAP-12374
>>>>>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40
>>>>>>>>> [3] https://issues.jboss.org/browse/WFLY-9574
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> wildfly-dev mailing list
>>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Brian Stansberry
>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>> Red Hat
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Brian Stansberry
>>>>>> Manager, Senior Principal Software Engineer
>>>>>> Red Hat
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Manager, Senior Principal Software Engineer
>>>>> Red Hat
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> Red Hat
>>>
>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>>
>
>


-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171206/c2410b38/attachment-0001.html 

From kkhan at redhat.com  Wed Dec  6 12:41:16 2017
From: kkhan at redhat.com (Kabir Khan)
Date: Wed, 6 Dec 2017 17:41:16 +0000
Subject: [wildfly-dev] Jirban board for WFLY feature requests/Jira
	cleanup
In-Reply-To: <2070B1EE-5757-40C4-9E97-2FA90472D0B0@redhat.com>
References: <E32E2A57-9946-4962-AA12-FD9944A0F47E@redhat.com>
	<0875B5B0-D263-496D-A862-4A48868C0903@redhat.com>
	<CAPhbRDbYDGY==cxADvC-SLD3H6KS2CBb=E179DjDhkpiW8_-zA@mail.gmail.com>
	<2070B1EE-5757-40C4-9E97-2FA90472D0B0@redhat.com>
Message-ID: <E02E69D3-6D07-4597-81D3-0A3E972A84A0@redhat.com>

The cleanup has completed. For the issues in [6] I took some guesses. They were comparing the update date with the WF Final releases, so they might be slightly off in some cases, but I left comments and enabled spam for these. If I got something wrong, please reopen, adjust the fix version, and resolve and close again.

Thanks,

Kabir

> On 6 Dec 2017, at 16:22, Kabir Khan <kkhan at redhat.com> wrote:
> 
> I am doing the bulk closures. I already had some complaints about the email spam, and there is a lot more to come. So, I will ask Jira not to send notifications for anything from the first set at least ([3] below).
> 
>> On 6 Dec 2017, at 13:52, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>> 
>> Closing issues after the .Final release is done sounds fine to me. We leave them Resolved until the .Final release is done because if something comes up and we need further work it's more of a pain to deal with a closed issue. But once the .Final release is done, I actually want it to be a pain to change the issue; e.g. reopening it because someone wants something more is usually wrong.
>> 
>> 10.x.x.TBD is the name of the "next release from the 10.x branch that we don't have any real plan to ever do, but we have the 10.x branch anyway just in case so here's a version to track activity on it" version. So things merged to 10.x since the last release have that version.
>> 
>> Re: "No Release" that's sometimes used for things that aren't really in the software or something versioned with the software and thus aren't in the release per se. Some of the stuff in that query looks like that; others just look like mistakes.
>> 
>> 
>> On Wed, Dec 6, 2017 at 6:05 AM, Kabir Khan <kkhan at redhat.com> wrote:
>> 
>> 
>>> On 6 Dec 2017, at 11:36, Kabir Khan <kkhan at redhat.com> wrote:
>>> 
>>> I have set up a Jirban board for WFLY, which can be found at [1] (log into issues.jboss.org first). It effectively uses the following JQL:
>>> 
>>>      project = WFLY and status != Closed and issuetype = "Feature Request" and (level is EMPTY and "Security Sensitive Issue" is EMPTY)
>>> 
>>> As you can see, it currently displays only feature requests.
>>> 
>>> However, if I organise this into swimlanes by fix version [2] it seems that there a lot of issues in the Resolved state for old releases.
>>> 
>>> I think these resolved issues should be closed. Firstly, I believe this is 'The Jira Way'. Secondly, it keeps the Jirban cache of issues on the server as small as possible, as the issues in the states configured to be 'done' in the Jirban config (i.e. Closed) are not cached. Also, the list of Fix Versions in the Jirban filters is populated from the issue data, so a nice side effect will be to keep that list more manageable. At the moment there are too many versions in there to make much sense out of it.
>>> 
>>> [3] contains a query for all issues in released versions. Here ' 10.x.x TBD' is a bit strange, but I assume these must have been released as part of something by now?
>>> 
>>> Then we have a few with Fix Version 'Awaiting Volunteers': [4]
>>> 
>>> There is a very mysterious Fix Version 'No Release': [5]
>>> 
>>> Then we have many resolved issues with no fix version but which have been done [6]
>>> 
>>> Finally we have a load of unresolved issues with no fix version which are rejected, duplicates, out of date etc. [7]
>>> 
>>> If my queries seem ok, I'd like to bulk close all of these. The ones from [4], [5] and [6] need a bit of care, but hopefully the date they were resolved can help figure out which release they went into. Or perhaps since they have been resolved with a strange fix version for so long, it doesn't matter if they are closed against that version either?
>>> 
>>> Thanks,
>>> 
>>> Kabir
>>> 
>>> 
>>> 
>>> [1] https://issues.jboss.org/jirban/index.html#/board?board=WFLY
>> [1] should have been https://issues.jboss.org/jirban/index.html#/board?board=WFLY-fr
>>> 
>>> [2] https://issues.jboss.org/jirban/index.html#/board?board=WFLY-fr&bl=true&swimlane=fix-version
>>> [3] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%20in%20(10.0.0.Alpha1%2C%20%2010.0.0.Alpha2%2C%20%2010.0.0.Alpha3%2C%2010.0.0.Alpha4%2C%2010.0.0.Alpha5%2C%2010.0.0.Alpha6%2C%2010.0.0.Beta1%2C%2010.0.0.Beta2%2C%2010.0.0.CR1%2C%2010.0.0.CR2%2C%20%2010.0.0.CR3%2C%20%2010.0.0.CR4%2C%2010.0.0.CR5%2C%2010.0.0.Final%2C%2010.1.0.CR1%2C%2010.1.0.Final%2C%20%2710.x.x%20TBD%27%2C%20%2011.0.0.Alpha1%2C%20%2011.0.0.Beta1%2C%20%2011.0.0.CR1%2C%20%2011.0.0.Final%2C%20%20%208.0.0.Alpha1%2C%20%208.0.0.Alpha2%2C%20%208.0.0.Alpha3%2C%20%208.0.0.Alpha4%2C%20%208.0.0.Beta1%2C%208.0.0.CR1%2C%20%208.0.0.Final%2C%208.1.0.CR1%2C%20%208.1.0.CR2%2C%20%208.1.0.Final%2C%20%208.2.0.Final%2C%20%209.0.0.Alpha1%2C%20%209.0.0.Beta1%2C%20%209.0.0.Beta2%2C%20%209.0.0.CR1%2C%20%209.0.0.CR2%2C%20%209.0.0.Final%2C%20%209.0.1.Final%2C%20%20%27JBoss%20AS7%207.1.1.Final%27)%0A
>>> [4] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%20in%20(%22Awaiting%20Volunteers%22)%0A
>>> [5] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%20in%20(%22No%20Release%22)%0A
>>> [6] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%20is%20EMPTY%20and%20resolution%20in%20(Done%2C%20%22Resolved%20at%20Apache%22)
>>> [7] https://issues.jboss.org/issues/?jql=project%20%3D%20WFLY%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%20is%20EMPTY%20and%20resolution%20not%20in%20(Done%2C%20%22Resolved%20at%20Apache%22)
>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> 
>> 
>> -- 
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
> 



From brian.stansberry at redhat.com  Wed Dec  6 12:43:03 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Wed, 6 Dec 2017 11:43:03 -0600
Subject: [wildfly-dev] Jirban board for WFLY feature requests/Jira
	cleanup
In-Reply-To: <E02E69D3-6D07-4597-81D3-0A3E972A84A0@redhat.com>
References: <E32E2A57-9946-4962-AA12-FD9944A0F47E@redhat.com>
	<0875B5B0-D263-496D-A862-4A48868C0903@redhat.com>
	<CAPhbRDbYDGY==cxADvC-SLD3H6KS2CBb=E179DjDhkpiW8_-zA@mail.gmail.com>
	<2070B1EE-5757-40C4-9E97-2FA90472D0B0@redhat.com>
	<E02E69D3-6D07-4597-81D3-0A3E972A84A0@redhat.com>
Message-ID: <CAPhbRDZvf5uJEbU-KBXVDBraaRX6zNiJZHV44A5u07b3+rSkRw@mail.gmail.com>

Thanks, Kabir!

On Wed, Dec 6, 2017 at 11:41 AM, Kabir Khan <kkhan at redhat.com> wrote:

> The cleanup has completed. For the issues in [6] I took some guesses. They
> were comparing the update date with the WF Final releases, so they might be
> slightly off in some cases, but I left comments and enabled spam for these.
> If I got something wrong, please reopen, adjust the fix version, and
> resolve and close again.
>
> Thanks,
>
> Kabir
>
> > On 6 Dec 2017, at 16:22, Kabir Khan <kkhan at redhat.com> wrote:
> >
> > I am doing the bulk closures. I already had some complaints about the
> email spam, and there is a lot more to come. So, I will ask Jira not to
> send notifications for anything from the first set at least ([3] below).
> >
> >> On 6 Dec 2017, at 13:52, Brian Stansberry <brian.stansberry at redhat.com>
> wrote:
> >>
> >> Closing issues after the .Final release is done sounds fine to me. We
> leave them Resolved until the .Final release is done because if something
> comes up and we need further work it's more of a pain to deal with a closed
> issue. But once the .Final release is done, I actually want it to be a pain
> to change the issue; e.g. reopening it because someone wants something more
> is usually wrong.
> >>
> >> 10.x.x.TBD is the name of the "next release from the 10.x branch that
> we don't have any real plan to ever do, but we have the 10.x branch anyway
> just in case so here's a version to track activity on it" version. So
> things merged to 10.x since the last release have that version.
> >>
> >> Re: "No Release" that's sometimes used for things that aren't really in
> the software or something versioned with the software and thus aren't in
> the release per se. Some of the stuff in that query looks like that; others
> just look like mistakes.
> >>
> >>
> >> On Wed, Dec 6, 2017 at 6:05 AM, Kabir Khan <kkhan at redhat.com> wrote:
> >>
> >>
> >>> On 6 Dec 2017, at 11:36, Kabir Khan <kkhan at redhat.com> wrote:
> >>>
> >>> I have set up a Jirban board for WFLY, which can be found at [1] (log
> into issues.jboss.org first). It effectively uses the following JQL:
> >>>
> >>>      project = WFLY and status != Closed and issuetype = "Feature
> Request" and (level is EMPTY and "Security Sensitive Issue" is EMPTY)
> >>>
> >>> As you can see, it currently displays only feature requests.
> >>>
> >>> However, if I organise this into swimlanes by fix version [2] it seems
> that there a lot of issues in the Resolved state for old releases.
> >>>
> >>> I think these resolved issues should be closed. Firstly, I believe
> this is 'The Jira Way'. Secondly, it keeps the Jirban cache of issues on
> the server as small as possible, as the issues in the states configured to
> be 'done' in the Jirban config (i.e. Closed) are not cached. Also, the list
> of Fix Versions in the Jirban filters is populated from the issue data, so
> a nice side effect will be to keep that list more manageable. At the moment
> there are too many versions in there to make much sense out of it.
> >>>
> >>> [3] contains a query for all issues in released versions. Here '
> 10.x.x TBD' is a bit strange, but I assume these must have been released as
> part of something by now?
> >>>
> >>> Then we have a few with Fix Version 'Awaiting Volunteers': [4]
> >>>
> >>> There is a very mysterious Fix Version 'No Release': [5]
> >>>
> >>> Then we have many resolved issues with no fix version but which have
> been done [6]
> >>>
> >>> Finally we have a load of unresolved issues with no fix version which
> are rejected, duplicates, out of date etc. [7]
> >>>
> >>> If my queries seem ok, I'd like to bulk close all of these. The ones
> from [4], [5] and [6] need a bit of care, but hopefully the date they were
> resolved can help figure out which release they went into. Or perhaps since
> they have been resolved with a strange fix version for so long, it doesn't
> matter if they are closed against that version either?
> >>>
> >>> Thanks,
> >>>
> >>> Kabir
> >>>
> >>>
> >>>
> >>> [1] https://issues.jboss.org/jirban/index.html#/board?board=WFLY
> >> [1] should have been https://issues.jboss.org/jirban/index.html#/board?
> board=WFLY-fr
> >>>
> >>> [2] https://issues.jboss.org/jirban/index.html#/board?
> board=WFLY-fr&bl=true&swimlane=fix-version
> >>> [3] https://issues.jboss.org/issues/?jql=project%20%3D%
> 20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%
> 20in%20(10.0.0.Alpha1%2C%20%2010.0.0.Alpha2%2C%20%2010.0.
> 0.Alpha3%2C%2010.0.0.Alpha4%2C%2010.0.0.Alpha5%2C%2010.0.
> 0.Alpha6%2C%2010.0.0.Beta1%2C%2010.0.0.Beta2%2C%2010.0.0.
> CR1%2C%2010.0.0.CR2%2C%20%2010.0.0.CR3%2C%20%2010.0.0.
> CR4%2C%2010.0.0.CR5%2C%2010.0.0.Final%2C%2010.1.0.CR1%2C%
> 2010.1.0.Final%2C%20%2710.x.x%20TBD%27%2C%20%2011.0.0.
> Alpha1%2C%20%2011.0.0.Beta1%2C%20%2011.0.0.CR1%2C%20%2011.
> 0.0.Final%2C%20%20%208.0.0.Alpha1%2C%20%208.0.0.Alpha2%
> 2C%20%208.0.0.Alpha3%2C%20%208.0.0.Alpha4%2C%20%208.0.0.
> Beta1%2C%208.0.0.CR1%2C%20%208.0.0.Final%2C%208.1.0.CR1%
> 2C%20%208.1.0.CR2%2C%20%208.1.0.Final%2C%20%208.2.0.Final%
> 2C%20%209.0.0.Alpha1%2C%20%209.0.0.Beta1%2C%20%209.0.0.
> Beta2%2C%20%209.0.0.CR1%2C%20%209.0.0.CR2%2C%20%209.0.0.
> Final%2C%20%209.0.1.Final%2C%20%20%27JBoss%20AS7%207.1.1.Final%27)%0A
> >>> [4] https://issues.jboss.org/issues/?jql=project%20%3D%
> 20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%
> 20in%20(%22Awaiting%20Volunteers%22)%0A
> >>> [5] https://issues.jboss.org/issues/?jql=project%20%3D%
> 20WFLY%20and%20status%20%3D%20Resolved%20and%20fixVersion%
> 20in%20(%22No%20Release%22)%0A
> >>> [6] https://issues.jboss.org/issues/?jql=project%20%3D%
> 20WFLY%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%
> 20is%20EMPTY%20and%20resolution%20in%20(Done%2C%
> 20%22Resolved%20at%20Apache%22)
> >>> [7] https://issues.jboss.org/issues/?jql=project%20%3D%
> 20WFLY%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%
> 20is%20EMPTY%20and%20resolution%20not%20in%20(Done%2C%20%22Resolved%20at%
> 20Apache%22)
> >>
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >>
> >>
> >> --
> >> Brian Stansberry
> >> Manager, Senior Principal Software Engineer
> >> Red Hat
> >
>
>


-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171206/6e6dc1a0/attachment.html 

From david.lloyd at redhat.com  Wed Dec  6 19:42:16 2017
From: david.lloyd at redhat.com (David Lloyd)
Date: Wed, 6 Dec 2017 18:42:16 -0600
Subject: [wildfly-dev] A quick PSA about Java 9's MR JARs and the
	maven-bundle-plugin
Message-ID: <CANghgrQggRQuoRXaocN73sn6+oyQX21mMvGVRcKBW9G-CG6ngA@mail.gmail.com>

Java 9 multi-release JARs [1] break [2] the maven-bundle-plugin due to
a bug in BND [3].  There is a workaround, however [4].

I guess I have to add "reinstate maven-bundle-plugin to projects" to
my TODO list.

[1] http://openjdk.java.net/jeps/238
[2] https://issues.apache.org/jira/browse/FELIX-5592
[3] https://github.com/bndtools/bnd/issues/2227
[4] https://issues.apache.org/jira/browse/FELIX-5592?focusedCommentId=16281169#comment-16281169

-- 
- DML

From ropalka at redhat.com  Thu Dec  7 02:25:48 2017
From: ropalka at redhat.com (Richard Opalka)
Date: Thu, 7 Dec 2017 08:25:48 +0100
Subject: [wildfly-dev] A quick PSA about Java 9's MR JARs and the
	maven-bundle-plugin
In-Reply-To: <CANghgrQggRQuoRXaocN73sn6+oyQX21mMvGVRcKBW9G-CG6ngA@mail.gmail.com>
References: <CANghgrQggRQuoRXaocN73sn6+oyQX21mMvGVRcKBW9G-CG6ngA@mail.gmail.com>
Message-ID: <CABSyOEE+sgGi-iaYx_W1MT171iOKOC_J2q4pyzjokiuO9UWT2A@mail.gmail.com>

Thanks for sharing David. It's good to know about that workaround.

Rio

On Thu, Dec 7, 2017 at 1:42 AM, David Lloyd <david.lloyd at redhat.com> wrote:

> Java 9 multi-release JARs [1] break [2] the maven-bundle-plugin due to
> a bug in BND [3].  There is a workaround, however [4].
>
> I guess I have to add "reinstate maven-bundle-plugin to projects" to
> my TODO list.
>
> [1] http://openjdk.java.net/jeps/238
> [2] https://issues.apache.org/jira/browse/FELIX-5592
> [3] https://github.com/bndtools/bnd/issues/2227
> [4] https://issues.apache.org/jira/browse/FELIX-5592?
> focusedCommentId=16281169#comment-16281169
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
--
Richard Opalka
Principal Software Engineer
Red Hat JBoss Middleware
Mobile: +420 731 186 942
E-mail: ropalka at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171207/1e76e84d/attachment.html 

From smarlow at redhat.com  Thu Dec  7 02:29:13 2017
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 7 Dec 2017 02:29:13 -0500
Subject: [wildfly-dev] Policies for merging PRs on master
In-Reply-To: <866285154.53034215.1512563465107.JavaMail.zimbra@redhat.com>
References: <CAKQecn95fhbz4w7SMBoc+QvSCbcyJ=7MsK_2V3QOqU-2Ja5xrQ@mail.gmail.com>
	<CANghgrRT+qD351=s0cNP24Rjz5ny9Ys8Axy3K-chbxQ8d+iPuw@mail.gmail.com>
	<CAKQecn-UrxaYG=Q-ELYLqDti0vcRzY-LwYCicbV600xqnUuULg@mail.gmail.com>
	<CAPhbRDY7rsynXLy1HR0+Cg5JLS_+CVBx3G+4QNuWXpW6aW2BfA@mail.gmail.com>
	<CAAoo=c6kTt9j-8moNkR1aDML0Mz88j0_y3x7G6Jwj_ctM_jncQ@mail.gmail.com>
	<1bdbcb2e-2a87-3218-b7ba-01728d7d2596@redhat.com>
	<CAPhbRDaAVT5RPuY1bd1+Ayi3rYaJGWDuotkiFTGo5vCLEgz4Jg@mail.gmail.com>
	<866285154.53034215.1512563465107.JavaMail.zimbra@redhat.com>
Message-ID: <CAJtdNN6UQFFeC7x0atUFc8tU=_xYXgQYpatFhDBywiJbYt4jAw@mail.gmail.com>

Excellent suggestions Rostislav!  There are some trade offs due to the
amount of time needed for each test run.  Whatever the implementation, it
would be good to have a prioritized way of running the tests that
accomplish a-c.

Scott

On Wed, Dec 6, 2017 at 7:31 AM, Rostislav Svoboda <rsvoboda at redhat.com>
wrote:

> I see 3 main use-cases for TCK runs outside WFLY master
>
>  a) pre-checks before final merging to WFLY master - master-ignore way
> discussed here
>  b) checks on big feature(s) development branches
>       something like ladybird or RFE development across multiple components
>       selected TCK modules can be executed, depends on scope of changes
>  c) regular component checks on component master
>       early / regression checks on component level that they do not regress
>       TCK modules related to the component and layered components should
> be executed
>       I know only few components which run related TCK modules with their
> master
>
> With proposed changes for quick WF delivery I believe use-cases b) and c)
> will need to be addressed.
>
> Use-cases b) and c) could be done on component level or via central
> pipeline.
>   component level - prepare automated way to run TCK with custom build -
> e.g. bash script, docker image
>   central pipeline - set of jobs can be prepared and linked via Jenkins
> pipeline so the end user (or curl request) provides just URL of custom WFLY
> build zip + list of modules to be executed
>
> Rostislav
>
> ----- Original Message -----
> > On Tue, Dec 5, 2017 at 4:37 AM, Scott Marlow < smarlow at redhat.com >
> wrote:
> >
> >
> > It would be great if we could have a branch that includes all of the
> commits
> > that we are considering to merge at a particular time of day, such that
> we
> > would run the TCK against that branch, only once a day.
> >
> > Can this be done that often? I had in my mind that if we did one of
> these it
> > would amount to stealing one of the regular runs, but perhaps that's not
> the
> > case.
> >
> > Now, I don't think we'd want to do these anywhere near that often, but
> it's
> > good to know what the limits would be. For example, I could imagine
> doing 10
> > of these over the course of a WF release, but by luck or whatever 3 of
> them
> > come in the same week.
> >
> > +1 to using a branch. We have a branch like that, master-ignore, that we
> use
> > for batching up PRs to test as a group before merging. I wouldn't want to
> > use master-ignore for this, but a differently named branch run the same
> way
> > sounds good.
> >
> >
> >
> > If one of the changes cause a TCK failure, none of them get merged
> > (investigation follows that to determine which change caused the
> > failure(s)), if the test succeeds, we can then merge that batch of
> changes
> > into WildFly master.
> >
> > We likely would want to avoid running the testing, on days when we
> haven't
> > merged any changes to the WF testing branching.
> >
> >
> > Can the TCK be set up to run based on a check for a change in the sha of
> the
> > head of a branch? So every day at a fixed time it checks the branch, and
> > does nothing if there is no change. If we want a run, we force push the
> > branch before that time. We have CI jobs that check master-ignore that
> way,
> > except they poll regularly, not just once a day. That works for those as
> > they aren't so resource intensive that we worry a lot about limiting how
> > often they run.
> >
> >
> > Would that approach help how we merge PRs on master?
> >
> >
> > I think it could be helpful earlier in the release cycle before merging
> big
> > changes, and then perhaps late in the release cycle if we're worried
> about
> > possible regressions.
> >
> >
> >
> > Scott
> >
> > On 12/04/2017 09:33 PM, Stuart Douglas wrote:
> >
> >
> >
> >
> > On Tue, Dec 5, 2017 at 3:40 AM, Brian Stansberry <
> > brian.stansberry at redhat.com <mailto: brian.stansberry at redhat.com >>
> wrote:
> >
> > Great. :)
> >
> > One thing I think we need to do is figure out how to get custom TCK
> > runs for PR branches. The TCK is a big part of our test coverage,
> > and one way to not "use master as a test bed" is to get a check of a
> > branch on the TCK before we merge it.
> >
> > I know we've gotten TCK runs of ad-hoc branches before, so by
> > "figure out" I mean work out how to make that not overly painful,
> > come to some sort of consensus on when it's worthwhile, etc.
> >
> >
> > I think if we were going to do this it should probably be something
> reviewers
> > can ask for on specific PR. The TCK uses a *lot* more resources than a
> > standard CI run, so we need to make sure we limit it to cases where it is
> > required.
> >
> > Stuart
> >
> >
> > On Fri, Dec 1, 2017 at 10:04 AM, Alessio Soldano
> > < asoldano at redhat.com <mailto: asoldano at redhat.com >> wrote:
> >
> > There you go... PR updated to consume the same api jar now
> > released as final.
> >
> > Cheers
> > Alessio
> >
> > On Fri, Dec 1, 2017 at 3:30 PM, David Lloyd
> > < david.lloyd at redhat.com <mailto: david.lloyd at redhat.com >> wrote:
> >
> > On Thu, Nov 30, 2017 at 5:50 PM, Alessio Soldano
> > < asoldano at redhat.com <mailto: asoldano at redhat.com >> wrote:
> > > As suggested by Brian, I'd like to draw attention to the discussion on
> > > https://github.com/wildfly/wildfly/pull/10604
> > < https://github.com/wildfly/wildfly/pull/10604 > .
> > > The PR is an upgrade of the webservices stack, including JBossWS,
> Apache
> > > CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade is for EE8
> and
> > > better JDK 9 compatibility.
> > > Now, due to the upgrade of the JAXB API spec jar, the PR is essentially
> > > stalled since 20 days; the new spec is released as an alpha (as it's
> been
> > > tested within JBossWS only) and that does not satisfy a rule that
> requires
> > > any artifact being pulled to be Final.
> > > We're talking about a spec jar, we could simply re-tag that as Final,
> > > chances are we won't need changes any time soon there anyway, but as
> Tomaz
> > > pointed out, in principle that would be dishonest.
> >
> > My opinion is that you should go ahead and make a .Final
> > tag. In the
> > (unlikely?) event that the spec has to be modified for some
> > reason, I
> > think you could make a 1.0.1.Final tag and call it a "bug fix".
> >
> > The alternative is to simply wait. I don't think there is
> > any middle position.
> >
> > > While I see the point in requiring that only sufficiently stable
> upgrades
> > > are applied to the codebase, I'm wondering whether, maybe, we're going
> a
> > > bit
> > > too far with the rules. Brian wrote on this topic: "how to determine
> that
> > > something is good enough to go in without using master as a test bed" ?
> >
> > I don't think we are; I agree with the policy as it stands. If you
> > look at it in terms of being able to release at any time,
> > then it
> > follows that everything _must_ be stable.
> >
> > --
> > - DML
> >
> >
> >
> > _______________________________________________
> > 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
> > < https://lists.jboss.org/mailman/listinfo/wildfly-dev >
> >
> >
> >
> >
> > -- Brian Stansberry
> > Manager, Senior Principal Software Engineer
> > 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
> > < 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
> > Manager, Senior Principal Software Engineer
> > 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/20171207/734174ce/attachment.html 

From cdewolf at redhat.com  Thu Dec  7 02:33:41 2017
From: cdewolf at redhat.com (Carlo de Wolf)
Date: Thu, 7 Dec 2017 08:33:41 +0100
Subject: [wildfly-dev] Policies for merging PRs on master
In-Reply-To: <CAJtdNN6UQFFeC7x0atUFc8tU=_xYXgQYpatFhDBywiJbYt4jAw@mail.gmail.com>
References: <CAKQecn95fhbz4w7SMBoc+QvSCbcyJ=7MsK_2V3QOqU-2Ja5xrQ@mail.gmail.com>
	<CANghgrRT+qD351=s0cNP24Rjz5ny9Ys8Axy3K-chbxQ8d+iPuw@mail.gmail.com>
	<CAKQecn-UrxaYG=Q-ELYLqDti0vcRzY-LwYCicbV600xqnUuULg@mail.gmail.com>
	<CAPhbRDY7rsynXLy1HR0+Cg5JLS_+CVBx3G+4QNuWXpW6aW2BfA@mail.gmail.com>
	<CAAoo=c6kTt9j-8moNkR1aDML0Mz88j0_y3x7G6Jwj_ctM_jncQ@mail.gmail.com>
	<1bdbcb2e-2a87-3218-b7ba-01728d7d2596@redhat.com>
	<CAPhbRDaAVT5RPuY1bd1+Ayi3rYaJGWDuotkiFTGo5vCLEgz4Jg@mail.gmail.com>
	<866285154.53034215.1512563465107.JavaMail.zimbra@redhat.com>
	<CAJtdNN6UQFFeC7x0atUFc8tU=_xYXgQYpatFhDBywiJbYt4jAw@mail.gmail.com>
Message-ID: <e366e45c-a8ec-d90c-03fd-40ee5b674a26@redhat.com>

EAP uses *-proposed branches for exactly these purposes.

Once we get green lights from all CI stations, the respective main 
branch is fast forwarded to the proposed state.

Carlo

On 07-12-17 08:29, Scott Marlow wrote:
> Excellent suggestions Rostislav!? There are some trade offs due to the 
> amount of time needed for each test run. Whatever the implementation, 
> it would be good to have a prioritized way of running the tests that 
> accomplish a-c.
>
> Scott
>
> On Wed, Dec 6, 2017 at 7:31 AM, Rostislav Svoboda <rsvoboda at redhat.com 
> <mailto:rsvoboda at redhat.com>> wrote:
>
>     I see 3 main use-cases for TCK runs outside WFLY master
>
>     ?a) pre-checks before final merging to WFLY master - master-ignore
>     way discussed here
>     ?b) checks on big feature(s) development branches
>     ? ? ? something like ladybird or RFE development across multiple
>     components
>     ? ? ? selected TCK modules can be executed, depends on scope of
>     changes
>     ?c) regular component checks on component master
>     ? ? ? early / regression checks on component level that they do
>     not regress
>     ? ? ? TCK modules related to the component and layered components
>     should be executed
>     ? ? ? I know only few components which run related TCK modules
>     with their master
>
>     With proposed changes for quick WF delivery I believe use-cases b)
>     and c) will need to be addressed.
>
>     Use-cases b) and c) could be done on component level or via
>     central pipeline.
>     ? component level - prepare automated way to run TCK with custom
>     build - e.g. bash script, docker image
>     ? central pipeline - set of jobs can be prepared and linked via
>     Jenkins pipeline so the end user (or curl request) provides just
>     URL of custom WFLY build zip + list of modules to be executed
>
>     Rostislav
>
>     ----- Original Message -----
>     > On Tue, Dec 5, 2017 at 4:37 AM, Scott Marlow <
>     smarlow at redhat.com <mailto:smarlow at redhat.com> > wrote:
>     >
>     >
>     > It would be great if we could have a branch that includes all of
>     the commits
>     > that we are considering to merge at a particular time of day,
>     such that we
>     > would run the TCK against that branch, only once a day.
>     >
>     > Can this be done that often? I had in my mind that if we did one
>     of these it
>     > would amount to stealing one of the regular runs, but perhaps
>     that's not the
>     > case.
>     >
>     > Now, I don't think we'd want to do these anywhere near that
>     often, but it's
>     > good to know what the limits would be. For example, I could
>     imagine doing 10
>     > of these over the course of a WF release, but by luck or
>     whatever 3 of them
>     > come in the same week.
>     >
>     > +1 to using a branch. We have a branch like that, master-ignore,
>     that we use
>     > for batching up PRs to test as a group before merging. I
>     wouldn't want to
>     > use master-ignore for this, but a differently named branch run
>     the same way
>     > sounds good.
>     >
>     >
>     >
>     > If one of the changes cause a TCK failure, none of them get merged
>     > (investigation follows that to determine which change caused the
>     > failure(s)), if the test succeeds, we can then merge that batch
>     of changes
>     > into WildFly master.
>     >
>     > We likely would want to avoid running the testing, on days when
>     we haven't
>     > merged any changes to the WF testing branching.
>     >
>     >
>     > Can the TCK be set up to run based on a check for a change in
>     the sha of the
>     > head of a branch? So every day at a fixed time it checks the
>     branch, and
>     > does nothing if there is no change. If we want a run, we force
>     push the
>     > branch before that time. We have CI jobs that check
>     master-ignore that way,
>     > except they poll regularly, not just once a day. That works for
>     those as
>     > they aren't so resource intensive that we worry a lot about
>     limiting how
>     > often they run.
>     >
>     >
>     > Would that approach help how we merge PRs on master?
>     >
>     >
>     > I think it could be helpful earlier in the release cycle before
>     merging big
>     > changes, and then perhaps late in the release cycle if we're
>     worried about
>     > possible regressions.
>     >
>     >
>     >
>     > Scott
>     >
>     > On 12/04/2017 09:33 PM, Stuart Douglas wrote:
>     >
>     >
>     >
>     >
>     > On Tue, Dec 5, 2017 at 3:40 AM, Brian Stansberry <
>     > brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>
>     <mailto: brian.stansberry at redhat.com
>     <mailto:brian.stansberry at redhat.com> >> wrote:
>     >
>     > Great. :)
>     >
>     > One thing I think we need to do is figure out how to get custom TCK
>     > runs for PR branches. The TCK is a big part of our test coverage,
>     > and one way to not "use master as a test bed" is to get a check of a
>     > branch on the TCK before we merge it.
>     >
>     > I know we've gotten TCK runs of ad-hoc branches before, so by
>     > "figure out" I mean work out how to make that not overly painful,
>     > come to some sort of consensus on when it's worthwhile, etc.
>     >
>     >
>     > I think if we were going to do this it should probably be
>     something reviewers
>     > can ask for on specific PR. The TCK uses a *lot* more resources
>     than a
>     > standard CI run, so we need to make sure we limit it to cases
>     where it is
>     > required.
>     >
>     > Stuart
>     >
>     >
>     > On Fri, Dec 1, 2017 at 10:04 AM, Alessio Soldano
>     > < asoldano at redhat.com <mailto:asoldano at redhat.com> <mailto:
>     asoldano at redhat.com <mailto:asoldano at redhat.com> >> wrote:
>     >
>     > There you go... PR updated to consume the same api jar now
>     > released as final.
>     >
>     > Cheers
>     > Alessio
>     >
>     > On Fri, Dec 1, 2017 at 3:30 PM, David Lloyd
>     > < david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>
>     <mailto: david.lloyd at redhat.com <mailto:david.lloyd at redhat.com> >>
>     wrote:
>     >
>     > On Thu, Nov 30, 2017 at 5:50 PM, Alessio Soldano
>     > < asoldano at redhat.com <mailto:asoldano at redhat.com> <mailto:
>     asoldano at redhat.com <mailto:asoldano at redhat.com> >> wrote:
>     > > As suggested by Brian, I'd like to draw attention to the
>     discussion on
>     > > https://github.com/wildfly/wildfly/pull/10604
>     <https://github.com/wildfly/wildfly/pull/10604>
>     > < https://github.com/wildfly/wildfly/pull/10604
>     <https://github.com/wildfly/wildfly/pull/10604> > .
>     > > The PR is an upgrade of the webservices stack, including
>     JBossWS, Apache
>     > > CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade is
>     for EE8 and
>     > > better JDK 9 compatibility.
>     > > Now, due to the upgrade of the JAXB API spec jar, the PR is
>     essentially
>     > > stalled since 20 days; the new spec is released as an alpha
>     (as it's been
>     > > tested within JBossWS only) and that does not satisfy a rule
>     that requires
>     > > any artifact being pulled to be Final.
>     > > We're talking about a spec jar, we could simply re-tag that as
>     Final,
>     > > chances are we won't need changes any time soon there anyway,
>     but as Tomaz
>     > > pointed out, in principle that would be dishonest.
>     >
>     > My opinion is that you should go ahead and make a .Final
>     > tag. In the
>     > (unlikely?) event that the spec has to be modified for some
>     > reason, I
>     > think you could make a 1.0.1.Final tag and call it a "bug fix".
>     >
>     > The alternative is to simply wait. I don't think there is
>     > any middle position.
>     >
>     > > While I see the point in requiring that only sufficiently
>     stable upgrades
>     > > are applied to the codebase, I'm wondering whether, maybe,
>     we're going a
>     > > bit
>     > > too far with the rules. Brian wrote on this topic: "how to
>     determine that
>     > > something is good enough to go in without using master as a
>     test bed" ?
>     >
>     > I don't think we are; I agree with the policy as it stands. If you
>     > look at it in terms of being able to release at any time,
>     > then it
>     > follows that everything _must_ be stable.
>     >
>     > --
>     > - DML
>     >
>     >
>     >
>     > _______________________________________________
>     > wildfly-dev mailing list
>     > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     <mailto: wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org> >
>     > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>     > < https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev> >
>     >
>     >
>     >
>     >
>     > -- Brian Stansberry
>     > Manager, Senior Principal Software Engineer
>     > Red Hat
>     >
>     > _______________________________________________
>     > wildfly-dev mailing list
>     > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     <mailto: wildfly-dev at lists.jboss.org
>     <mailto:wildfly-dev at lists.jboss.org> >
>     > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>     > < https://lists.jboss.org/mailman/listinfo/wildfly-dev
>     <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
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>     >
>     >
>     >
>     >
>     > --
>     > Brian Stansberry
>     > Manager, Senior Principal Software Engineer
>     > 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
>     <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/20171207/de4a51b1/attachment-0001.html 

From rsvoboda at redhat.com  Thu Dec  7 03:15:38 2017
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Thu, 7 Dec 2017 03:15:38 -0500 (EST)
Subject: [wildfly-dev] Policies for merging PRs on master
In-Reply-To: <CAJtdNN6UQFFeC7x0atUFc8tU=_xYXgQYpatFhDBywiJbYt4jAw@mail.gmail.com>
References: <CAKQecn95fhbz4w7SMBoc+QvSCbcyJ=7MsK_2V3QOqU-2Ja5xrQ@mail.gmail.com>
	<CAKQecn-UrxaYG=Q-ELYLqDti0vcRzY-LwYCicbV600xqnUuULg@mail.gmail.com>
	<CAPhbRDY7rsynXLy1HR0+Cg5JLS_+CVBx3G+4QNuWXpW6aW2BfA@mail.gmail.com>
	<CAAoo=c6kTt9j-8moNkR1aDML0Mz88j0_y3x7G6Jwj_ctM_jncQ@mail.gmail.com>
	<1bdbcb2e-2a87-3218-b7ba-01728d7d2596@redhat.com>
	<CAPhbRDaAVT5RPuY1bd1+Ayi3rYaJGWDuotkiFTGo5vCLEgz4Jg@mail.gmail.com>
	<866285154.53034215.1512563465107.JavaMail.zimbra@redhat.com>
	<CAJtdNN6UQFFeC7x0atUFc8tU=_xYXgQYpatFhDBywiJbYt4jAw@mail.gmail.com>
Message-ID: <1968853667.53214711.1512634538743.JavaMail.zimbra@redhat.com>


> Excellent suggestions Rostislav!  There are some trade offs due to the
> amount of time needed for each test run.  Whatever the implementation, it

If there is prepared script or docker image TCK execution could be offloaded from your TCK Jenkins to components (component Central CI instance or their bare-metal machine/notebook)

> would be good to have a prioritized way of running the tests that
> accomplish a-c.

On script / job / docker level:
 - instead of list of modules to be executed you would need two lists - list of prioritized modules and list regular modules + add delay before triggering regular modules
 - add weigh to the "list"

Jenkins itself can prioritize some jobs, we used it to prioritize acceptance testing jobs in MW Jenkins to have early results.
This way you could have priority on regular WFLY master / master-ignore jobs (or the other way) in your TCK Jenkins.

Rostislav

> Scott
> 
> On Wed, Dec 6, 2017 at 7:31 AM, Rostislav Svoboda <rsvoboda at redhat.com>
> wrote:
> 
> > I see 3 main use-cases for TCK runs outside WFLY master
> >
> >  a) pre-checks before final merging to WFLY master - master-ignore way
> > discussed here
> >  b) checks on big feature(s) development branches
> >       something like ladybird or RFE development across multiple components
> >       selected TCK modules can be executed, depends on scope of changes
> >  c) regular component checks on component master
> >       early / regression checks on component level that they do not regress
> >       TCK modules related to the component and layered components should
> > be executed
> >       I know only few components which run related TCK modules with their
> > master
> >
> > With proposed changes for quick WF delivery I believe use-cases b) and c)
> > will need to be addressed.
> >
> > Use-cases b) and c) could be done on component level or via central
> > pipeline.
> >   component level - prepare automated way to run TCK with custom build -
> > e.g. bash script, docker image
> >   central pipeline - set of jobs can be prepared and linked via Jenkins
> > pipeline so the end user (or curl request) provides just URL of custom WFLY
> > build zip + list of modules to be executed
> >
> > Rostislav
> >
> > ----- Original Message -----
> > > On Tue, Dec 5, 2017 at 4:37 AM, Scott Marlow < smarlow at redhat.com >
> > wrote:
> > >
> > >
> > > It would be great if we could have a branch that includes all of the
> > commits
> > > that we are considering to merge at a particular time of day, such that
> > we
> > > would run the TCK against that branch, only once a day.
> > >
> > > Can this be done that often? I had in my mind that if we did one of
> > these it
> > > would amount to stealing one of the regular runs, but perhaps that's not
> > the
> > > case.
> > >
> > > Now, I don't think we'd want to do these anywhere near that often, but
> > it's
> > > good to know what the limits would be. For example, I could imagine
> > doing 10
> > > of these over the course of a WF release, but by luck or whatever 3 of
> > them
> > > come in the same week.
> > >
> > > +1 to using a branch. We have a branch like that, master-ignore, that we
> > use
> > > for batching up PRs to test as a group before merging. I wouldn't want to
> > > use master-ignore for this, but a differently named branch run the same
> > way
> > > sounds good.
> > >
> > >
> > >
> > > If one of the changes cause a TCK failure, none of them get merged
> > > (investigation follows that to determine which change caused the
> > > failure(s)), if the test succeeds, we can then merge that batch of
> > changes
> > > into WildFly master.
> > >
> > > We likely would want to avoid running the testing, on days when we
> > haven't
> > > merged any changes to the WF testing branching.
> > >
> > >
> > > Can the TCK be set up to run based on a check for a change in the sha of
> > the
> > > head of a branch? So every day at a fixed time it checks the branch, and
> > > does nothing if there is no change. If we want a run, we force push the
> > > branch before that time. We have CI jobs that check master-ignore that
> > way,
> > > except they poll regularly, not just once a day. That works for those as
> > > they aren't so resource intensive that we worry a lot about limiting how
> > > often they run.
> > >
> > >
> > > Would that approach help how we merge PRs on master?
> > >
> > >
> > > I think it could be helpful earlier in the release cycle before merging
> > big
> > > changes, and then perhaps late in the release cycle if we're worried
> > about
> > > possible regressions.
> > >
> > >
> > >
> > > Scott
> > >
> > > On 12/04/2017 09:33 PM, Stuart Douglas wrote:
> > >
> > >
> > >
> > >
> > > On Tue, Dec 5, 2017 at 3:40 AM, Brian Stansberry <
> > > brian.stansberry at redhat.com <mailto: brian.stansberry at redhat.com >>
> > wrote:
> > >
> > > Great. :)
> > >
> > > One thing I think we need to do is figure out how to get custom TCK
> > > runs for PR branches. The TCK is a big part of our test coverage,
> > > and one way to not "use master as a test bed" is to get a check of a
> > > branch on the TCK before we merge it.
> > >
> > > I know we've gotten TCK runs of ad-hoc branches before, so by
> > > "figure out" I mean work out how to make that not overly painful,
> > > come to some sort of consensus on when it's worthwhile, etc.
> > >
> > >
> > > I think if we were going to do this it should probably be something
> > reviewers
> > > can ask for on specific PR. The TCK uses a *lot* more resources than a
> > > standard CI run, so we need to make sure we limit it to cases where it is
> > > required.
> > >
> > > Stuart
> > >
> > >
> > > On Fri, Dec 1, 2017 at 10:04 AM, Alessio Soldano
> > > < asoldano at redhat.com <mailto: asoldano at redhat.com >> wrote:
> > >
> > > There you go... PR updated to consume the same api jar now
> > > released as final.
> > >
> > > Cheers
> > > Alessio
> > >
> > > On Fri, Dec 1, 2017 at 3:30 PM, David Lloyd
> > > < david.lloyd at redhat.com <mailto: david.lloyd at redhat.com >> wrote:
> > >
> > > On Thu, Nov 30, 2017 at 5:50 PM, Alessio Soldano
> > > < asoldano at redhat.com <mailto: asoldano at redhat.com >> wrote:
> > > > As suggested by Brian, I'd like to draw attention to the discussion on
> > > > https://github.com/wildfly/wildfly/pull/10604
> > > < https://github.com/wildfly/wildfly/pull/10604 > .
> > > > The PR is an upgrade of the webservices stack, including JBossWS,
> > Apache
> > > > CXF, JAXB-RI and JAXB API. In particular, the JAXB upgrade is for EE8
> > and
> > > > better JDK 9 compatibility.
> > > > Now, due to the upgrade of the JAXB API spec jar, the PR is essentially
> > > > stalled since 20 days; the new spec is released as an alpha (as it's
> > been
> > > > tested within JBossWS only) and that does not satisfy a rule that
> > requires
> > > > any artifact being pulled to be Final.
> > > > We're talking about a spec jar, we could simply re-tag that as Final,
> > > > chances are we won't need changes any time soon there anyway, but as
> > Tomaz
> > > > pointed out, in principle that would be dishonest.
> > >
> > > My opinion is that you should go ahead and make a .Final
> > > tag. In the
> > > (unlikely?) event that the spec has to be modified for some
> > > reason, I
> > > think you could make a 1.0.1.Final tag and call it a "bug fix".
> > >
> > > The alternative is to simply wait. I don't think there is
> > > any middle position.
> > >
> > > > While I see the point in requiring that only sufficiently stable
> > upgrades
> > > > are applied to the codebase, I'm wondering whether, maybe, we're going
> > a
> > > > bit
> > > > too far with the rules. Brian wrote on this topic: "how to determine
> > that
> > > > something is good enough to go in without using master as a test bed" ?
> > >
> > > I don't think we are; I agree with the policy as it stands. If you
> > > look at it in terms of being able to release at any time,
> > > then it
> > > follows that everything _must_ be stable.
> > >
> > > --
> > > - DML
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
> > > < https://lists.jboss.org/mailman/listinfo/wildfly-dev >
> > >
> > >
> > >
> > >
> > > -- Brian Stansberry
> > > Manager, Senior Principal Software Engineer
> > > 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
> > > < 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
> > > Manager, Senior Principal Software Engineer
> > > Red Hat
> > >
> > > _______________________________________________
> > > wildfly-dev mailing list
> > > wildfly-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> 

From girionis at yahoo.com  Thu Dec  7 05:53:40 2017
From: girionis at yahoo.com (Panos Konstantinidis)
Date: Thu, 7 Dec 2017 10:53:40 +0000 (UTC)
Subject: [wildfly-dev] write-timeout and ClosedChannelException
References: <75515765.274361.1512644020220.ref@mail.yahoo.com>
Message-ID: <75515765.274361.1512644020220@mail.yahoo.com>

Hello,
apologies in advance if this is not the right place to ask questions, but I have some questions that require in-depth understanding of Wildfly and it seems that the users' forum is not the right place to ask them.?We have a Wildfly instance installed (wildfly-10.1.0.Final) on standalone mode. We have added a write-timeout="45000" to http-listener & https-listener on production, but we noticed that we get a lot of ClosedChannelException errors:?java.nio.channels.ClosedChannelException: nullat io.undertow.conduits.WriteTimeoutStreamSinkConduit.handleWriteTimeout(WriteTimeoutStreamSinkConduit.java:106)at io.undertow.conduits.WriteTimeoutStreamSinkConduit.write(WriteTimeoutStreamSinkConduit.java:122)?I would have expected to only see WriteTimeoutException errors, as described here (WildFly 10.0 Model Reference?), which we do, but very occasionally.?By looking at the undertow code (io.undertow.conduits.WriteTimeoutStreamSinkConduit) I noticed that the ClosedChannelException is thrown at the following piece of code:???????? if (expireTimeVar != -1 && currentTime > expireTimeVar) {??????????? IoUtils.safeClose(connection);??????????? throw new ClosedChannelException();??????? }?We managed to reproduce the problem on the UAT environment, with the following settings:???????????????? <http-listener name="default" tcp-keep-alive="false" read-timeout="45000" write-timeout="10000" socket-binding="http" record-request-start-time="true" redirect-socket="https" enable-http2="true"/>??????????????? <https-listener name="https" tcp-keep-alive="false" read-timeout="45000" write-timeout="10000" socket-binding="https" record-request-start-time="true" security-realm="ApplicationRealm" enable-http2="true"/>
and also with the following:
? ? ? ? ? ? ? ? <http-listener name="default" tcp-keep-alive="true" read-timeout="45000" write-timeout="10000" socket-binding="http" record-request-start-time="true" redirect-socket="https" enable-http2="true"/>??????????????? <https-listener name="https" tcp-keep-alive="true" read-timeout="45000" write-timeout="10000" socket-binding="https" record-request-start-time="true" security-realm="ApplicationRealm" enable-http2="true"/>
We cloned the undertow code and changed the WriteTimeoutStreamSinkConduit.java ourselves (we just added a few debug statements), rebuilt the undertow-core-1.4.0.Final.jar and replaced the one in the UAT environment with our custom version. I noticed the following in the logs?[INFO ] 2017-12-05?12:48:57.240 [default task-6] [pt0_WuRKH4rsd6yPRrXen53Ee2OiPGlNed64iFrI]?stdout [?:?] - Updating expire time to: currentTime: 1512470937239 + timeout: 10000[INFO ] 2017-12-05?12:49:11.452 [default task-4] [pt0_WuRKH4rsd6yPRrXen53Ee2OiPGlNed64iFrI]?stdout [?:?] - Timeout is set to: 10000[INFO ] 2017-12-05 12:49:11.453 [default task-4] [pt0_WuRKH4rsd6yPRrXen53Ee2OiPGlNed64iFrI] stdout [?:?] - currentTime is: 1512470951453 and expireTime is: 1512470947239[INFO ] 2017-12-05 12:49:11.454 [default task-4] [pt0_WuRKH4rsd6yPRrXen53Ee2OiPGlNed64iFrI] stdout [?:?] - currentTime > expireTimeVar: true[ERROR] 2017-12-05 12:49:11.455 [default task-4] [pt0_WuRKH4rsd6yPRrXen53Ee2OiPGlNed64iFrI] g.c.RestExceptionHandler [RestExceptionHandler.java:24] - Exception Thrown: java.nio.channels.ClosedChannelException?If you notice we are talking about two different requests (different thread name) under the same user (same session id) with 14'' delay. I *guess* this exception occurs because the same socket is reused for both requests (for both? threads) and thus the expire time applies for all requests over the same socket. But in this case I would expect a WriteTimeoutException, as explained in the docs. So my questions are:?a) How exactly does the write-timeout work? I would have thought that each new request resets the timer.b) Why don't I get a WriteTimeoutException instead? There are days that we see hundreds of ClosedChannelException but no WriteTimeoutException.c) Is there any way to avoid the ClosedChannelException? None of our users has complained yet, but the stack traces clog our log files.?Regards?Panos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171207/676970d4/attachment-0001.html 

From jperkins at redhat.com  Thu Dec  7 15:02:47 2017
From: jperkins at redhat.com (James Perkins)
Date: Thu, 7 Dec 2017 12:02:47 -0800
Subject: [wildfly-dev] Logging Changes
Message-ID: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>

Hello All,
For WildFly 12 (maybe not until 13 at this stage) there are some thoughts
on significantly changing the way logging is configured. Currently logging
is initialized by reading a logging.properties file when JBoss Modules
boots. While this works okay there are a few issues with this approach.


   1. For boot logging (before the logging subsystem is initialized) you
   can't use property expressions. This means when the logging subsystem
   rewrites the logging.properties file with all expressions expanded.
   2. Logging objects, such as handlers, cannot use resources from other
   subsystems. For example there is a need for a socket-handler. With the
   socket handler we need a way to get an SSL context from Elytron. There is
   no way for this to be done using a logging.properties file for the boot log
   configuration.
   3. If the user want to manually change the logging configuration by
   editing the XML they also have to edit the logging.properties. If not the
   old configuration will be used until the next boot.

It would be useful to introduce a way to queue log messages during boot
[1]. Once the logging subsystem boot is complete the messages would be
drained and sent to the new configuration. This of course isn't without
it's own issues.


   1. Messages appeared delayed when WildFly is booting. Essentially all
   the boot messages are written at once so you see no messages, then all of
   them at once.
   2. A shutdown hook would have to be used in order to ensure errors that
   cause a boot failure are logged.
   3. This could get a little tricky with offline CLI as currently logging
   is configured based on the logging.properties file
   4. If users remove the logging subsystem there are more steps than just
   removing logging subsystem to get logging working.
   5. There will be a slight performance impact during boot. This can be
   greatly reduced if the caller calculation is disabled. This can be done in
   normal cases, but we likely can't make it the default. Note too this is
   only a boot impact. Once the logging subsystem takes over, the performance
   should be exactly the same as it was before.

There is some good however too. This does open the door allowing users to
more easily replace the log manager implementation for standalone servers.
Currently we still, and maybe always will, require the JBoss Log Manager to
be used for domain servers, the host controller and process controller.

It also removes the need for a logging.properties for servers. I think this
is a big bonus to the changes as logging for servers will only be
configured in one place now. Domain will be a bit different, but we should
likely introduce a logging subsystem on the host controller as well. I just
don't think it makes much sense until we can sort out the issues above.

The current idea is that boot logging will be configurable via system
properties. These properties would have to be set in the JAVA_OPTS.

I'm curious to hear any concerns others might have about this. This feels
like a rather significant change so I'd rather get it right the first time.

I have started a design doc, but it's not finalized yet. If you're curious
however you can have at look at it on my topic branch [2]. You can also see
some of the small changes I've made to get it working on WildFly Core on
that branch.


[1]: https://issues.jboss.org/browse/LOGMGR-177
[2]:
https://github.com/jamezp/wildfly-core/blob/bootstrap-logging/logging/bootstrap-logging.asciidoc

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

From david.lloyd at redhat.com  Thu Dec  7 18:46:43 2017
From: david.lloyd at redhat.com (David Lloyd)
Date: Thu, 7 Dec 2017 17:46:43 -0600
Subject: [wildfly-dev] Logging Changes
In-Reply-To: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
References: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
Message-ID: <CANghgrRrbV_ksi8FBOSQthc1XLsVrc-sNyBGz69tJFgD00GFiQ@mail.gmail.com>

On Thu, Dec 7, 2017 at 2:02 PM, James Perkins <jperkins at redhat.com> wrote:
> There will be a slight performance impact during boot. This can be greatly
> reduced if the caller calculation is disabled. This can be done in normal
> cases, but we likely can't make it the default.

I suspect we can safely disable caller calculation by default on boot,
as long as users have an easy way to turn it on.

Also I think we should consider some kind of grimy hack to bootstrap
the logging subsystem first, if it's present, otherwise immediately
fall back to properties-based config if it's absent.

-- 
- DML

From ropalka at redhat.com  Fri Dec  8 05:47:50 2017
From: ropalka at redhat.com (Richard Opalka)
Date: Fri, 8 Dec 2017 11:47:50 +0100
Subject: [wildfly-dev] Logging Changes
In-Reply-To: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
References: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
Message-ID: <CABSyOEFUC2hJ-torQWnRbXUAcuzhfmrTP+7vu0rwa3E1Mfmgbg@mail.gmail.com>

Hi James (all),

   What you outlined above is similar to effort [1] that was done for JDK 9.
Are there are any plans integrating this effort somehow with JDK9 or better
reuse what JDK9 already provides?
   I was doing some research few months back (but I didn't finish it yet)
how
logging is done in JDK9. I was hoping for better JBoss-Logging integration
with JDK9 logging.
   Although I didn't finish it yet I'm posting here few analysis documents
I have created so far. I hope they will be helpful.

Rio

[1] http://openjdk.java.net/jeps/158


On Thu, Dec 7, 2017 at 9:02 PM, James Perkins <jperkins at redhat.com> wrote:

> Hello All,
> For WildFly 12 (maybe not until 13 at this stage) there are some thoughts
> on significantly changing the way logging is configured. Currently logging
> is initialized by reading a logging.properties file when JBoss Modules
> boots. While this works okay there are a few issues with this approach.
>
>
>    1. For boot logging (before the logging subsystem is initialized) you
>    can't use property expressions. This means when the logging subsystem
>    rewrites the logging.properties file with all expressions expanded.
>    2. Logging objects, such as handlers, cannot use resources from other
>    subsystems. For example there is a need for a socket-handler. With the
>    socket handler we need a way to get an SSL context from Elytron. There is
>    no way for this to be done using a logging.properties file for the boot log
>    configuration.
>    3. If the user want to manually change the logging configuration by
>    editing the XML they also have to edit the logging.properties. If not the
>    old configuration will be used until the next boot.
>
> It would be useful to introduce a way to queue log messages during boot
> [1]. Once the logging subsystem boot is complete the messages would be
> drained and sent to the new configuration. This of course isn't without
> it's own issues.
>
>
>    1. Messages appeared delayed when WildFly is booting. Essentially all
>    the boot messages are written at once so you see no messages, then all of
>    them at once.
>    2. A shutdown hook would have to be used in order to ensure errors
>    that cause a boot failure are logged.
>    3. This could get a little tricky with offline CLI as currently
>    logging is configured based on the logging.properties file
>    4. If users remove the logging subsystem there are more steps than
>    just removing logging subsystem to get logging working.
>    5. There will be a slight performance impact during boot. This can be
>    greatly reduced if the caller calculation is disabled. This can be done in
>    normal cases, but we likely can't make it the default. Note too this is
>    only a boot impact. Once the logging subsystem takes over, the performance
>    should be exactly the same as it was before.
>
> There is some good however too. This does open the door allowing users to
> more easily replace the log manager implementation for standalone servers.
> Currently we still, and maybe always will, require the JBoss Log Manager to
> be used for domain servers, the host controller and process controller.
>
> It also removes the need for a logging.properties for servers. I think
> this is a big bonus to the changes as logging for servers will only be
> configured in one place now. Domain will be a bit different, but we should
> likely introduce a logging subsystem on the host controller as well. I just
> don't think it makes much sense until we can sort out the issues above.
>
> The current idea is that boot logging will be configurable via system
> properties. These properties would have to be set in the JAVA_OPTS.
>
> I'm curious to hear any concerns others might have about this. This feels
> like a rather significant change so I'd rather get it right the first time.
>
> I have started a design doc, but it's not finalized yet. If you're curious
> however you can have at look at it on my topic branch [2]. You can also see
> some of the small changes I've made to get it working on WildFly Core on
> that branch.
>
>
> [1]: https://issues.jboss.org/browse/LOGMGR-177
> [2]: https://github.com/jamezp/wildfly-core/blob/
> bootstrap-logging/logging/bootstrap-logging.asciidoc
>
> --
> 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
>



-- 
--
Richard Opalka
Principal Software Engineer
Red Hat JBoss Middleware
Mobile: +420 731 186 942
E-mail: ropalka at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171208/6740e15a/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JdkLazyLogger_use_via_System.Logger_iface.pdf
Type: application/pdf
Size: 28678 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171208/6740e15a/attachment-0004.pdf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JdkLazyLogger_use_via_PlatformLogger_iface.pdf
Type: application/pdf
Size: 35330 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171208/6740e15a/attachment-0005.pdf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JDK9_System_Logger_Usage_Sequence_Diagram.pdf
Type: application/pdf
Size: 26515 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171208/6740e15a/attachment-0006.pdf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JDK9_Platform_Logger_Usage_Sequence_Diagram.pdf
Type: application/pdf
Size: 19334 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171208/6740e15a/attachment-0007.pdf 

From tdiesler at redhat.com  Fri Dec  8 07:46:22 2017
From: tdiesler at redhat.com (Thomas Diesler)
Date: Fri, 8 Dec 2017 13:46:22 +0100
Subject: [wildfly-dev] WildFly-Camel 5.0.0 released
Message-ID: <992D6880-D089-4EB2-9016-C0B11650319E@redhat.com>

Folks,

I happy to announce that WildFly-Camel 5.0.0 <https://github.com/wildfly-extras/wildfly-camel/releases/tag/5.0.0> has been released.
It provides Camel-2.20.1 integration with WildFly-11.0.0 

This is a major upgrade release for supported components, dataformats and languages, which now reaches feature parity with other runtimes. 
i.e. all available dataformats and languages are now also supported on WildFly.

Additional components in the supported set <http://wildfly-extras.github.io/wildfly-camel/#_camel_components> are:

	? apns
	? asterisk
	? atomix
	? azure-blob
	? azure-queue
	? beanstalk
	? caffeine
	? chronicle-engine
	? chunk
	? cm-sms
	? consul
	? couchbase
	? crypto-cms
	? digitalocean
	? docker
	? elasticsearch5
	? etcd
	? flink
	? google-bigquery
	? google-calendar
	? google-drive
	? google-mail
	? grpc
	? guava-eventbus
	? hazelcast
	? headersmap
	? hipchat
	? iec60870
	? jclouds
	? jcr
	? json-validator
	? jt400
	? ldif
	? leveldb
	? lumberjack
	? master
	? milo
	? mongodb-gridfs
	? nagios
	? olingo4
	? openstack-cinder
	? openstack-glance
	? openstack-keystone
	? openstack-neutron
	? openstack-nova
	? openstack-swift
	? printer
	? pubnub
	? quickfix
	? reactor
	? rmi
	? shiro
	? sip
	? sips
	? slack
	? spring-javaconfig
	? spring-ws
	? stomp
	? telegram
	? thrift
	? twilio
	? xmpp
	? yammer
	? zookeeper-master

Additional data formats in the supported set <http://wildfly-extras.github.io/wildfly-camel/#_data_formats> are:

	? asn1
	? fastjson
	? thrift

Component upgrades include

	? WildFly-11.0.0
	? Camel-2.20.1
	? Hawtio-1.5.5

In addition to that, we also resolved a number of other tasks and bugs <https://github.com/wildfly-extras/wildfly-camel/blob/master/docs/Changelog.md>.

For details please see the 5.0.0 Milestone <https://github.com/wildfly-extras/wildfly-camel/issues?q=milestone:5.0.0>.

Enjoy
? thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171208/1e7b4615/attachment.html 

From br.roglusa at gmail.com  Fri Dec  8 09:40:52 2017
From: br.roglusa at gmail.com (=?UTF-8?Q?Rog=C3=A9rio_Luciano_Santos?=)
Date: Fri, 8 Dec 2017 12:40:52 -0200
Subject: [wildfly-dev] XWiki in WildFly 10
Message-ID: <CAFCKAGLbt5kz29KHW-ByGDBc_ifKAspn+EXSp_r45KRhJQKoHw@mail.gmail.com>

Hello.

Does anyone know XWIKI? i Want deply  the xwiki war in WildFly 10 by  a
error occurs:

Cannot upload deployment: {"WFLYCTL0080: Failed services" =>
{"jboss.deployment.unit.\"xwiki-9.10.1.war\".POST_MODULE" =>
"org.jboss.msc.service.StartException in service
jboss.deployment.unit.\"xwiki-9.10.1.war\".POST_MODULE: WFLYSRV0153: Failed
to process phase POST_MODULE of deployment \"xwiki-9.10.1.war\" Caused by:
java.lang.RuntimeException: WFLYSRV0177: Error getting reflective
information for class com.codahale.metrics.jetty9.InstrumentedHandler$7
with ClassLoader ModuleClassLoader for Module
\"deployment.xwiki-9.10.1.war:main\" from Service Module Loader Caused by:
java.lang.NoClassDefFoundError: Failed to link
com/codahale/metrics/jetty9/InstrumentedHandler (Module
\"deployment.xwiki-9.10.1.war:main\" from Service Module Loader):
org/eclipse/jetty/server/handler/HandlerWrapper"},"WFLYCTL0412: Required
services that are not installed:" =>
["jboss.deployment.unit.\"xwiki-9.10.1.war\".POST_MODULE"],"WFLYCTL0180:
Services with missing/unavailable dependencies" => undefined}

This application run in a glassfish server
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171208/da82b3f1/attachment.html 

From filippespolti at gmail.com  Fri Dec  8 11:12:23 2017
From: filippespolti at gmail.com (Spolti)
Date: Fri, 8 Dec 2017 14:12:23 -0200
Subject: [wildfly-dev] XWiki in WildFly 10
In-Reply-To: <CAFCKAGLbt5kz29KHW-ByGDBc_ifKAspn+EXSp_r45KRhJQKoHw@mail.gmail.com>
References: <CAFCKAGLbt5kz29KHW-ByGDBc_ifKAspn+EXSp_r45KRhJQKoHw@mail.gmail.com>
Message-ID: <CAOp2QgEk22u6Z9nHYnh2rLKF=_Dnmy0YNKpnRgPh5PmnBUGHEg@mail.gmail.com>

Caused by: java.lang.NoClassDefFoundError: Failed to link
com/codahale/metrics/jetty9/InstrumentedHandler

You need to add this class in the classloader,

You can create a module and specify it in the
jboss-deployment-structure.xml file or add this jar in you .war file.



2017-12-08 12:40 GMT-02:00 Rog?rio Luciano Santos <br.roglusa at gmail.com>:

>
> Hello.
>
> Does anyone know XWIKI? i Want deply  the xwiki war in WildFly 10 by  a
> error occurs:
>
> Cannot upload deployment: {"WFLYCTL0080: Failed services" =>
> {"jboss.deployment.unit.\"xwiki-9.10.1.war\".POST_MODULE" =>
> "org.jboss.msc.service.StartException in service
> jboss.deployment.unit.\"xwiki-9.10.1.war\".POST_MODULE: WFLYSRV0153:
> Failed to process phase POST_MODULE of deployment \"xwiki-9.10.1.war\"
> Caused by: java.lang.RuntimeException: WFLYSRV0177: Error getting
> reflective information for class com.codahale.metrics.jetty9.InstrumentedHandler$7
> with ClassLoader ModuleClassLoader for Module \"deployment.xwiki-9.10.1.war:main\"
> from Service Module Loader Caused by: java.lang.NoClassDefFoundError:
> Failed to link com/codahale/metrics/jetty9/InstrumentedHandler (Module
> \"deployment.xwiki-9.10.1.war:main\" from Service Module Loader):
> org/eclipse/jetty/server/handler/HandlerWrapper"},"WFLYCTL0412: Required
> services that are not installed:" => ["jboss.deployment.unit.\"
> xwiki-9.10.1.war\".POST_MODULE"],"WFLYCTL0180: Services with
> missing/unavailable dependencies" => undefined}
>
> This application run in a glassfish server
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
Regards,
--Filippe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171208/7475d4ee/attachment-0001.html 

From ebenzacar at gmail.com  Fri Dec  8 23:04:11 2017
From: ebenzacar at gmail.com (Eric B)
Date: Fri, 8 Dec 2017 23:04:11 -0500
Subject: [wildfly-dev] request.getSession() returns a different object for
 each request - Undertow's session object is the object retrieved by
 request.getSession()
Message-ID: <CA+T+PjFJ6H_JbugxCm9bnkwmecN4tPsN3-r4_oD3JEQUSx9XMA@mail.gmail.com>

I'm migrating a legacy (circa 2005) n-tier JBoss 4 application to run in
Wildfly 10.  It was a struggle, but got pretty much everything done.  We've
been trying as hard as possible not to refactor logic/code/etc except in
the cases where it is simply no longer compatible.  The goal was to get the
application working "as-is" in WF, then start tackling the job of breaking
it apart and refactoring it into proper pieces.

The problem I have run into now is regarding session management.  The
application was designed to run on multiple nodes, but in standalone
instances - ie: there is no shared memory, nor any distributed caches.  So
I'm trying to get my WF10 application to follow the same pattern (even
though I realize all this exists in WF10 out of the box with
Infinispan/etc).

One of the requirements is to only have a single session active for a user
at any time in the "cluster".  The JB4 application accomplished this by
maintaining a local cache (HashMap) of session objects keyed by username.
When a user logs into any node, a JMS message is broadcast to all the nodes
to invalidate any session belonging to that user.  The listener on each
node then searches in his cache for a matching user/session object and does
a session.invalidate().  Some extra logic is used for WeakReferences for
the session objects (in case the session is destroyed by some other flow in
the container).

As ugly as the solution was, we've tried to follow the same pattern under
WF10.  But this is failing in many different ways and reinforces my belief
that it isn't the right approach.  However, I would like to understand
how/why this is failing.

My server configuration is using a <local-cache> for my "web" cache.  So to
me this means it is only local to the machine.  But:

1) on any specific node, request.getSession() returns a different object
for each request.  The sessionId() remains the same, but the actual object
ID changes.  This implies that it is a different representation of the
session object.

2) if I persist a local copy of the HttpSession object between requests
(ex: in a static map) and invalidate the session using the persisted
object, my request.getSession() object is not updated (ex: the invalid flag
is still set to false), but the session is dead.  Trying to call
request.getSession().invalidate() throws IllegalStateException as do calls
to request.getSession().set/getAttribute()

3) over time, my JVM will actually crash with an EXCEPTION_ACCESS_VIOLATION
in a GC process.  This always seems to correlate with a thread that is
trying to do some session invalidation via the persisted session copy.


Is anyone able to explain this behaviour?  Why is the session object always
different between requests?  Shouldn't it be the same request?  What is
Undertow doing with the session objects between requests?  Is the Undertow
object being passivated in some way and my attempt to invalidate if from
within my cached version causing this kind of access violation?  Is my
cached object referencing memory that has been cleared by the GC (ex: does
the request.getSession() object only a WeakReference to the actual Undertow
object)?


Finally, what would the recommended approach be to doing something like
this?  Using a distributed web-cache is unfortunately not an option at the
moment.  So give that, is there some way to access the Undertow session
manager directly?

Thanks for any insight.  I thought we had a functional solution but in
production (under real load), the intermittent JVM crashes are telling me
that our solution is broken.

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171208/529df183/attachment.html 

From stuart.w.douglas at gmail.com  Sun Dec 10 18:01:37 2017
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Mon, 11 Dec 2017 10:01:37 +1100
Subject: [wildfly-dev] request.getSession() returns a different object
 for each request - Undertow's session object is the object retrieved by
 request.getSession()
In-Reply-To: <CA+T+PjFJ6H_JbugxCm9bnkwmecN4tPsN3-r4_oD3JEQUSx9XMA@mail.gmail.com>
References: <CA+T+PjFJ6H_JbugxCm9bnkwmecN4tPsN3-r4_oD3JEQUSx9XMA@mail.gmail.com>
Message-ID: <CAAoo=c4n4QycQNjVp6DuF5veSRU_fhZ6C4Qw3xd1SjfqoKFSSQ@mail.gmail.com>

On Sat, Dec 9, 2017 at 3:04 PM, Eric B <ebenzacar at gmail.com> wrote:

> I'm migrating a legacy (circa 2005) n-tier JBoss 4 application to run in
> Wildfly 10.  It was a struggle, but got pretty much everything done.  We've
> been trying as hard as possible not to refactor logic/code/etc except in
> the cases where it is simply no longer compatible.  The goal was to get the
> application working "as-is" in WF, then start tackling the job of breaking
> it apart and refactoring it into proper pieces.
>
> The problem I have run into now is regarding session management.  The
> application was designed to run on multiple nodes, but in standalone
> instances - ie: there is no shared memory, nor any distributed caches.  So
> I'm trying to get my WF10 application to follow the same pattern (even
> though I realize all this exists in WF10 out of the box with
> Infinispan/etc).
>
> One of the requirements is to only have a single session active for a user
> at any time in the "cluster".  The JB4 application accomplished this by
> maintaining a local cache (HashMap) of session objects keyed by username.
> When a user logs into any node, a JMS message is broadcast to all the nodes
> to invalidate any session belonging to that user.  The listener on each
> node then searches in his cache for a matching user/session object and does
> a session.invalidate().  Some extra logic is used for WeakReferences for
> the session objects (in case the session is destroyed by some other flow in
> the container).
>
> As ugly as the solution was, we've tried to follow the same pattern under
> WF10.  But this is failing in many different ways and reinforces my belief
> that it isn't the right approach.  However, I would like to understand
> how/why this is failing.
>
> My server configuration is using a <local-cache> for my "web" cache.  So
> to me this means it is only local to the machine.  But:
>
> 1) on any specific node, request.getSession() returns a different object
> for each request.  The sessionId() remains the same, but the actual object
> ID changes.  This implies that it is a different representation of the
> session object.
>

Undertow returns a different facade for each request. Undertow uses its
internal representation of a session (io.undertow.server.session.Session)
that is stored in the session manager, and wraps a facade around it
(io.undertow.servlet.spec.HttpSessionImpl) that implements Servlet
semantics.


>
> 2) if I persist a local copy of the HttpSession object between requests
> (ex: in a static map) and invalidate the session using the persisted
> object, my request.getSession() object is not updated (ex: the invalid flag
> is still set to false), but the session is dead.  Trying to call
> request.getSession().invalidate() throws IllegalStateException as do
> calls to request.getSession().set/getAttribute()
>

I guess this could be considered a bug in that isNew will not throw an
IllegalStateException, which is the only place that the invalid flag is
used without also consulting the underlying session, but you sound as if
you expect the session to still work after it has been invalidated?

There is no requirement that the same session is represented by a single
java object, and especially it in a distributed environment this is not
possible. Even though we could keep the same facade around for all requests
this can encourage people to write apps that rely on this behaviour, and
also increases the likelihood that the facade will become tenured and
require a full GC to be reclaimed.


>
> 3) over time, my JVM will actually crash with an
> EXCEPTION_ACCESS_VIOLATION in a GC process.  This always seems to correlate
> with a thread that is trying to do some session invalidation via the
> persisted session copy.
>

This is a JVM bug. Which JVM are you using?

To implement this I would remove the WeakReference which will not work with
Undertow's session management strategy, and instead register a listener to
remove the session from the local map when it is invalidated. If you really
want to access the underlying Undertow session you can
call io.undertow.servlet.spec.HttpSessionImpl#getSession() to return the
Underlying Undertow session, although it should not be necessary.

Stuart



>
> Is anyone able to explain this behaviour?  Why is the session object
> always different between requests?  Shouldn't it be the same request?  What
> is Undertow doing with the session objects between requests?  Is the
> Undertow object being passivated in some way and my attempt to invalidate
> if from within my cached version causing this kind of access violation?  Is
> my cached object referencing memory that has been cleared by the GC (ex:
> does the request.getSession() object only a WeakReference to the actual
> Undertow object)?
>
>
> Finally, what would the recommended approach be to doing something like
> this?  Using a distributed web-cache is unfortunately not an option at the
> moment.  So give that, is there some way to access the Undertow session
> manager directly?
>
> Thanks for any insight.  I thought we had a functional solution but in
> production (under real load), the intermittent JVM crashes are telling me
> that our solution is broken.
>
> Eric
>
> _______________________________________________
> 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/20171211/0da1a9fe/attachment.html 

From ebenzacar at gmail.com  Sun Dec 10 23:01:48 2017
From: ebenzacar at gmail.com (Eric B)
Date: Sun, 10 Dec 2017 23:01:48 -0500
Subject: [wildfly-dev] request.getSession() returns a different object
 for each request - Undertow's session object is the object retrieved by
 request.getSession()
In-Reply-To: <CAAoo=c4n4QycQNjVp6DuF5veSRU_fhZ6C4Qw3xd1SjfqoKFSSQ@mail.gmail.com>
References: <CA+T+PjFJ6H_JbugxCm9bnkwmecN4tPsN3-r4_oD3JEQUSx9XMA@mail.gmail.com>
	<CAAoo=c4n4QycQNjVp6DuF5veSRU_fhZ6C4Qw3xd1SjfqoKFSSQ@mail.gmail.com>
Message-ID: <CA+T+PjHF1aQ73P-bmxXdvzTO=jpZ5q3bOUww8vP8-4aDXL-_2A@mail.gmail.com>

Hi Stuart,

Thanks for the reply.  A few followup questions if you don't mind.


>> 1) on any specific node, request.getSession() returns a different object
>> for each request.  The sessionId() remains the same, but the actual object
>> ID changes.  This implies that it is a different representation of the
>> session object.
>>
>
> Undertow returns a different facade for each request. Undertow uses its
> internal representation of a session (io.undertow.server.session.Session)
> that is stored in the session manager, and wraps a facade around it
> (io.undertow.servlet.spec.HttpSessionImpl) that implements Servlet
> semantics.
>

That's what I had assumed as well, based on the behaviour I had noticed.
Thanks for confirming.


>
>
>>
>> 2) if I persist a local copy of the HttpSession object between requests
>> (ex: in a static map) and invalidate the session using the persisted
>> object, my request.getSession() object is not updated (ex: the invalid flag
>> is still set to false), but the session is dead.  Trying to call
>> request.getSession().invalidate() throws IllegalStateException as do
>> calls to request.getSession().set/getAttribute()
>>
>
> I guess this could be considered a bug in that isNew will not throw an
> IllegalStateException, which is the only place that the invalid flag is
> used without also consulting the underlying session, but you sound as if
> you expect the session to still work after it has been invalidated?
>

No - quite the opposite actually.  I'm expecting that all session objects
to react the same after it has been invalidated.  If I use one of the
facades from a prior request to invalidate the session, I would expect that
every facade would respect the same state.  For instance, if I do the
following:

Request 1:

// store a copy of the session object to be available in a later request
static Session cachedSessionObj = request.getSession();


Request 2:

// invalidate the session from the cached object
cachedSessoinObject.invalidate();

// get a new session
Session newSession = request.getSession();


I would expect that cachedSessionObj.getId() != newSessoin.getId().

However, the request.getSession() doesn't get a new session object.  Rather
it still returns the old (now invalidated) session object.  So any logic
that is dependent on having a fresh session object fails (since the session
object is returned is actually the invalidated session).



> There is no requirement that the same session is represented by a single
> java object, and especially it in a distributed environment this is not
> possible. Even though we could keep the same facade around for all requests
> this can encourage people to write apps that rely on this behaviour, and
> also increases the likelihood that the facade will become tenured and
> require a full GC to be reclaimed.
>

Understood.


>
>> 3) over time, my JVM will actually crash with an
>> EXCEPTION_ACCESS_VIOLATION in a GC process.  This always seems to correlate
>> with a thread that is trying to do some session invalidation via the
>> persisted session copy.
>>
>
> This is a JVM bug. Which JVM are you using?
>
I'm running Oracle Hotspot Java 8x64 on a Windows platform (server 2016).
I've tried with both patch 131 and 151, and both exhibit the same
behaviour.

To implement this I would remove the WeakReference which will not work with
> Undertow's session management strategy, and instead register a listener to
> remove the session from the local map when it is invalidated. If you really
> want to access the underlying Undertow session you can
> call io.undertow.servlet.spec.HttpSessionImpl#getSession() to return the
> Underlying Undertow session, although it should not be necessary.
>

I've already removed the WeakReference as soon as I noticed that the
session facade returned by Undertow changed at each request.  I am using a
session listener to remove it from the local map when it is invalidated,
but I need an ability for an JMS listener to be able to invalidate a
session object based on an id it receives.

How can I access Undertow's SessionManager from within my application?  Is
there any way I can retrieve it from the CDI?  I tried adding
the io.undertow.core module to my jboss-deployment-structure.xml, but yet I
can't access it via injection or
via: CDI.current().getBeanManager().getBeans(SessionManager.class); in both
cases it is unable to find the SessionManager class.  Is there some other
way I can access it/retrieve it from within my application?


Thanks,

Eric





> Is anyone able to explain this behaviour?  Why is the session object
>> always different between requests?  Shouldn't it be the same request?  What
>> is Undertow doing with the session objects between requests?  Is the
>> Undertow object being passivated in some way and my attempt to invalidate
>> if from within my cached version causing this kind of access violation?  Is
>> my cached object referencing memory that has been cleared by the GC (ex:
>> does the request.getSession() object only a WeakReference to the actual
>> Undertow object)?
>>
>>
>> Finally, what would the recommended approach be to doing something like
>> this?  Using a distributed web-cache is unfortunately not an option at the
>> moment.  So give that, is there some way to access the Undertow session
>> manager directly?
>>
>> Thanks for any insight.  I thought we had a functional solution but in
>> production (under real load), the intermittent JVM crashes are telling me
>> that our solution is broken.
>>
>> Eric
>>
>> _______________________________________________
>> 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/20171210/8de14ded/attachment-0001.html 

From stuart.w.douglas at gmail.com  Sun Dec 10 23:14:35 2017
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Mon, 11 Dec 2017 15:14:35 +1100
Subject: [wildfly-dev] request.getSession() returns a different object
 for each request - Undertow's session object is the object retrieved by
 request.getSession()
In-Reply-To: <CA+T+PjHF1aQ73P-bmxXdvzTO=jpZ5q3bOUww8vP8-4aDXL-_2A@mail.gmail.com>
References: <CA+T+PjFJ6H_JbugxCm9bnkwmecN4tPsN3-r4_oD3JEQUSx9XMA@mail.gmail.com>
	<CAAoo=c4n4QycQNjVp6DuF5veSRU_fhZ6C4Qw3xd1SjfqoKFSSQ@mail.gmail.com>
	<CA+T+PjHF1aQ73P-bmxXdvzTO=jpZ5q3bOUww8vP8-4aDXL-_2A@mail.gmail.com>
Message-ID: <CAAoo=c4YO2fEMLck3Qt4h4V0Lb3y6iLVW4=hjS4pQOvT=+O15g@mail.gmail.com>

On Mon, Dec 11, 2017 at 3:01 PM, Eric B <ebenzacar at gmail.com> wrote:

> Hi Stuart,
>
> Thanks for the reply.  A few followup questions if you don't mind.
>
>
>>> 1) on any specific node, request.getSession() returns a different object
>>> for each request.  The sessionId() remains the same, but the actual object
>>> ID changes.  This implies that it is a different representation of the
>>> session object.
>>>
>>
>> Undertow returns a different facade for each request. Undertow uses its
>> internal representation of a session (io.undertow.server.session.Session)
>> that is stored in the session manager, and wraps a facade around it
>> (io.undertow.servlet.spec.HttpSessionImpl) that implements Servlet
>> semantics.
>>
>
> That's what I had assumed as well, based on the behaviour I had noticed.
> Thanks for confirming.
>
>
>>
>>
>>>
>>> 2) if I persist a local copy of the HttpSession object between requests
>>> (ex: in a static map) and invalidate the session using the persisted
>>> object, my request.getSession() object is not updated (ex: the invalid flag
>>> is still set to false), but the session is dead.  Trying to call
>>> request.getSession().invalidate() throws IllegalStateException as do
>>> calls to request.getSession().set/getAttribute()
>>>
>>
>> I guess this could be considered a bug in that isNew will not throw an
>> IllegalStateException, which is the only place that the invalid flag is
>> used without also consulting the underlying session, but you sound as if
>> you expect the session to still work after it has been invalidated?
>>
>
> No - quite the opposite actually.  I'm expecting that all session objects
> to react the same after it has been invalidated.  If I use one of the
> facades from a prior request to invalidate the session, I would expect that
> every facade would respect the same state.  For instance, if I do the
> following:
>
> Request 1:
>
> // store a copy of the session object to be available in a later request
> static Session cachedSessionObj = request.getSession();
>
>
> Request 2:
>
> // invalidate the session from the cached object
> cachedSessoinObject.invalidate();
>
> // get a new session
> Session newSession = request.getSession();
>
>
> I would expect that cachedSessionObj.getId() != newSessoin.getId().
>
> However, the request.getSession() doesn't get a new session object.
> Rather it still returns the old (now invalidated) session object.  So any
> logic that is dependent on having a fresh session object fails (since the
> session object is returned is actually the invalidated session).
>

Once a session has been assigned to the request it does not change. This is
a bit of a grey area.


>
>
>
>> There is no requirement that the same session is represented by a single
>> java object, and especially it in a distributed environment this is not
>> possible. Even though we could keep the same facade around for all requests
>> this can encourage people to write apps that rely on this behaviour, and
>> also increases the likelihood that the facade will become tenured and
>> require a full GC to be reclaimed.
>>
>
> Understood.
>
>
>>
>>> 3) over time, my JVM will actually crash with an
>>> EXCEPTION_ACCESS_VIOLATION in a GC process.  This always seems to correlate
>>> with a thread that is trying to do some session invalidation via the
>>> persisted session copy.
>>>
>>
>> This is a JVM bug. Which JVM are you using?
>>
> I'm running Oracle Hotspot Java 8x64 on a Windows platform (server 2016).
> I've tried with both patch 131 and 151, and both exhibit the same
> behaviour.
>

I would report it to Oracle.


>
> To implement this I would remove the WeakReference which will not work
>> with Undertow's session management strategy, and instead register a
>> listener to remove the session from the local map when it is invalidated.
>> If you really want to access the underlying Undertow session you can
>> call io.undertow.servlet.spec.HttpSessionImpl#getSession() to return the
>> Underlying Undertow session, although it should not be necessary.
>>
>
> I've already removed the WeakReference as soon as I noticed that the
> session facade returned by Undertow changed at each request.  I am using a
> session listener to remove it from the local map when it is invalidated,
> but I need an ability for an JMS listener to be able to invalidate a
> session object based on an id it receives.
>
> How can I access Undertow's SessionManager from within my application?  Is
> there any way I can retrieve it from the CDI?  I tried adding
> the io.undertow.core module to my jboss-deployment-structure.xml, but yet
> I can't access it via injection or via: CDI.current().
> getBeanManager().getBeans(SessionManager.class); in both cases it is
> unable to find the SessionManager class.  Is there some other way I can
> access it/retrieve it from within my application?
>

You can
do io.undertow.servlet.spec.ServletContextImpl#getSession(java.lang.String)
to get an arbitrary session.

If you want the actual SessionManager you would need to
call io.undertow.servlet.spec.ServletContextImpl#getDeployment().getSessionManager().

Stuart


>
>
> Thanks,
>
> Eric
>
>
>
>
>
>> Is anyone able to explain this behaviour?  Why is the session object
>>> always different between requests?  Shouldn't it be the same request?  What
>>> is Undertow doing with the session objects between requests?  Is the
>>> Undertow object being passivated in some way and my attempt to invalidate
>>> if from within my cached version causing this kind of access violation?  Is
>>> my cached object referencing memory that has been cleared by the GC (ex:
>>> does the request.getSession() object only a WeakReference to the actual
>>> Undertow object)?
>>>
>>>
>>> Finally, what would the recommended approach be to doing something like
>>> this?  Using a distributed web-cache is unfortunately not an option at the
>>> moment.  So give that, is there some way to access the Undertow session
>>> manager directly?
>>>
>>> Thanks for any insight.  I thought we had a functional solution but in
>>> production (under real load), the intermittent JVM crashes are telling me
>>> that our solution is broken.
>>>
>>> Eric
>>>
>>> _______________________________________________
>>> 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/20171211/17c0a50f/attachment.html 

From stuart.w.douglas at gmail.com  Mon Dec 11 00:10:58 2017
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Mon, 11 Dec 2017 16:10:58 +1100
Subject: [wildfly-dev] GRPC subsystem proof of concept
Message-ID: <CAAoo=c5XKAs5=u5shjA=p-puAqu0+HtS14U+f_KjqVVqH1_urg@mail.gmail.com>

Hi everyone,

I have done up a proof of concept of GRPC support in Wildfly, which can be
found at [1]. GRPC is an RPC protocol designed by Google, that allows for
easy cross platform invocations.

My proof of concept uses an Undertow based port of GRPC [2] and basically
works as follows:

- At deployment time Jandex is used to find all non-abstract classes that
implement io.grpc.BindableService
- I scan the class hierarchy of these classes to find the protobuf
generated base class, and create a subclass of this class using
ProxyFactory, overriding every method except bindService().
- An instance/proxy is created using the ComponentRegistry to do the
creation, and the generated proxy delegates all incoming calls to this
instance
- At runtime any incoming HTTP/2 requests with a type of application/grpc
are intercepted, and passed through this newly created proxy.

Basically this means that all you need to do as an application developer is
define your GRPC endpoints using protobuf, implement the classes generated
by the protobuf compiler and then include them in your application, and
Wildfly will do the rest. CDI and EJB annotations on your GRPC services
should work as normal, for example if you put @Stateless on an endpoint it
should work as expected with a SFSB handling all invocations.

Note that this is a very early stage POC, and lots of stuff is missing
(most notably security).

Before I go to much further though I though that I should get some
feedback, e.g.

- Do we actually want this? I am not sure how much interest there is, but
it seems like GRPC could be very useful in a polyglot microservice
environment.
- Is the current implementation the best way of actually registering GRPC
services, or should we require some kind of defining annotation
- What security mechanisms should we support? Out of the box standard GRPC
is fairly limited
- What do we do about transactions? I am leaning towards not supporting
them over GRPC, as we already have solutions for Java invocation in the
form of our EJB protocol, and I think non-Java clients are unlikely to want
to use this.

Stuart

[1] https://github.com/stuartwdouglas/wildfly/tree/grpc
[2] https://github.com/stuartwdouglas/undertow-grpc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171211/635ce519/attachment-0001.html 

From belaran at redhat.com  Mon Dec 11 07:47:29 2017
From: belaran at redhat.com (Romain Pelisse)
Date: Mon, 11 Dec 2017 13:47:29 +0100
Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have
 POSIX permissions perfectly set
In-Reply-To: <CAPhbRDZAnSLP6OYkWUHkvczj-sm4FGaE6apEEoiGRo_D+Z=nww@mail.gmail.com>
References: <CALuBA_p5Mqag2+TSD9bUWGM5BgDpirdZC7zvL5OE8w-HfA4AWw@mail.gmail.com>
	<CAPhbRDYyGwNpqFq8bYdRk53_hx6Mg4yHwOcmmYYnwDp_3-B+_A@mail.gmail.com>
	<CALuBA_pSvfNYPug1byQrS7Bic45vVvvdQ4Mjd-BQ6Pa4t5m05g@mail.gmail.com>
	<CAPhbRDYnYLd-SXuE_m_2b14W9VwNhy08KDpC0MdP6n3mipMi0A@mail.gmail.com>
	<CAPhbRDZFTd52gO8-psaaXJSVNAPn=3MtjA3XuyEC501Hj-rRJw@mail.gmail.com>
	<CALuBA_pXT89PNspojT-sT3GNTVhf1R1F7YJPxn7K-B6dmP4+bg@mail.gmail.com>
	<CAPhbRDZFfcuS5kZNHU99cVDSTjewsVynuaZAAxsxdQSswxOZOA@mail.gmail.com>
	<CAPhbRDYN_PGP8fo6BizQ3EOR-=9UT_jrJEECzLBfT-DoOt05fg@mail.gmail.com>
	<CALuBA_qxu=nGP93yfPXEdhiUdxBkQ2C7YZx=82i7qbOA=egr+A@mail.gmail.com>
	<CAPhbRDZAnSLP6OYkWUHkvczj-sm4FGaE6apEEoiGRo_D+Z=nww@mail.gmail.com>
Message-ID: <CALuBA_pfzAOsZf_fU=sN6uGkCdm04iwAwxJyV4r4gEkupSp2HQ@mail.gmail.com>

Hi all,

Not too much involvement except from Brian and I :) - sadly, we cannot move
forward on this topic without a minimum of consensus. If you don't to
participate, can you at least reply "+1 Brian" (if you think we should NOT
try to change the current behavior") or "+1 Romain" (if you think we should
address this issue somehow).

(please don't vote on the PR I've proposed, it's just a proposal on HOW we
could do it - here I want to assert IF we want to do it, not voting on the
"how").

On Wed, Dec 6, 2017 at 6:05 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> On Wed, Dec 6, 2017 at 4:27 AM, Romain Pelisse <belaran at redhat.com> wrote:
>
>> Hi Brian (and all),
>>
>> I honestly understand your resistance, and I'm completely fine if we end
>> up closing this all issue as WONTDO or REJECTED. I just do want to have a
>> discussion about it and come back with clear reasons and motivations for
>> changing or not the privileges of each of those files.
>>
>
> Thanks for doing this! There have been a number of issues filed over the
> last year or so on this general topic so I'm very happy to see them getting
> addressed here via the WildFly community. Most of the issues I've been
> talking about are JBEAP issues in JIRA, which is fine, but the best way to
> get this solid is to get WildFly the way we want it first.
>
> Even on the config file read perms thing I mentioned in my last post, I'm
> personally resistant to changing it, but my biggest resistance is to doing
> that without a full community discussion.
>
>
>> Given that we see different things on our local setup, I think the best
>> will be to use a build on a CI Server and works from what we see there. Is
>> there an easy way for me to clone a job building Wildfly and tweak it on
>> some (publicly) accessible instance ?
>>
>
> https://developer.jboss.org/thread/224262 describes how to get a zip
> built from a daily CI job.
>
> If anyone has any insights on this, please speak up!
>
>
>>
>>
>> On Mon, Dec 4, 2017 at 6:48 PM, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>>
>>> A slightly different topic, related to the "logging.properties/xml
>>> config file" topic is whether these files should be world and/or group
>>> readable.
>>>
>>> Changing this has been proposed in the past on the EAP side, primarily
>>> based on the argument that users could put sensitive data in these files.
>>> This thread seems like a good time to debate this a bit in community.
>>>
>>> I've resisted that primarily on the basis of:
>>>
>>> 1) These files or those similarly used have had these perms as far back
>>> as I can find in JBoss AS. So the odds that some people are relying upon
>>> those perms is fairly high and we need to assume a change would be a
>>> breaking change for some people.
>>>
>>> 2) Other software I've looked at like Tomcat and httpd have similar
>>> permission schemes to what we have for their config files, which can also
>>> potentially include sensitive data.
>>>
>>> 3) We provide facilities like the vault or elytron credential store refs
>>> for keeping sensitive data out of the config files.
>>>
>>>
>>> On Mon, Dec 4, 2017 at 11:38 AM, Brian Stansberry <
>>> brian.stansberry at redhat.com> wrote:
>>>
>>>> Thanks, Romain.
>>>>
>>>> Re: what the actual permissions are, FWIW I get what I see on both my
>>>> macbook and my Fedora 27 machine, both when unzipping the actual
>>>> 11.0.0.Final and when unzipping the result of a build of master, and both
>>>> with and without the -Prelease -Pjboss-release args to maven that we
>>>> include when doing actual releases. Unzipping the zip in build/target
>>>> doesn't include the jars of course.
>>>>
>>>> So it sounds like we need input from others.
>>>>
>>>> Re: modules.xml, if you are seeing those as rw-r--r-- as well, then +1
>>>> to ignoring them in further discussion.
>>>>
>>>> Re: logging.properties, those serve a very similar conceptual role to
>>>> the standalone|host|domain.xml files so I see no reason for them to have
>>>> different perms. However, you and I are getting different results, where
>>>> you report them as group writable and I don't. What do you see for the xml
>>>> config files?
>>>>
>>>> Re: RPM changing to match WildFly, that's an EAP discussion, so that
>>>> can be taken up elsewhere once we have WildFly the way we want it.
>>>>
>>>>
>>>> On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse <belaran at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi Brian and all,
>>>>>
>>>>> err, my own observation differs from yours. I've rebuild Wildfly from
>>>>> the last content of the master branch and get the same privileges on the
>>>>> jboss-modules.jar (so -rw-rw-r-- and not as you are seeing  rwxr--r--).
>>>>> Same with the domain folder, which turns out on my local system associated
>>>>> to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a
>>>>> transcript of what I did - maybe you can spot why our results differs so
>>>>> much.
>>>>>
>>>>> $ git show
>>>>> commit 46e119c65d9e32bc0ec69f3933267fece959ed3f
>>>>> Merge: 051f080 c7d9075
>>>>> Author: Kabir Khan <kkhan at redhat.com>
>>>>> Date:   Tue Nov 28 17:46:40 2017 +0000
>>>>>
>>>>>     Merge pull request #10669 from praxeo/WFLY-9284
>>>>>
>>>>>     WFLY-9284 Correct MVN env variable to mvnw.cmd
>>>>>
>>>>> $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d
>>>>> wildfly-12.zip
>>>>> ...
>>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.
>>>>> jar
>>>>> -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov.  11:41
>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
>>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/  -d
>>>>> drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov.  11:41
>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/
>>>>>
>>>>> Checking all the jars in the distribution, they all appears to have
>>>>> the mask '-rw-rw-r--':
>>>>>
>>>>> $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done | sed
>>>>> -e '/-rw-rw-r--/d'
>>>>> $
>>>>>
>>>>> Regarding properties files, here is the exhaustive list of properties
>>>>> that RPM packaging has modified the privileges of:
>>>>>
>>>>> appclient/configuration/logging.properties rw-------
>>>>> domain/configuration/application-roles.properties rw-------
>>>>> domain/configuration/default-server-logging.properties rw-------
>>>>> domain/configuration/logging.properties rw-------
>>>>> domain/configuration/mgmt-groups.properties rw-------
>>>>> standalone/configuration/application-roles.properties rw-------
>>>>> standalone/configuration/logging.properties rw-------
>>>>> standalone/configuration/mgmt-groups.properties rw-------
>>>>>
>>>>> If I compare that with the content of the extract zip (same fresh
>>>>> built as above), I can see that 4 files are not having the same mask
>>>>> (rw------):
>>>>>
>>>>> $ for file in $(cut -f1 -d\  ../../../list-props-files.txt ); do ls -l
>>>>> $file ; done
>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>>>> appclient/configuration/logging.properties
>>>>> -rw-------. 1 rpelisse rpelisse 710 30 nov.  11:41
>>>>> domain/configuration/application-roles.properties
>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>>>> domain/configuration/default-server-logging.properties
>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>>>> domain/configuration/logging.properties
>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>>>> domain/configuration/mgmt-groups.properties
>>>>> -rw-------. 1 rpelisse rpelisse 711 30 nov.  11:41
>>>>> standalone/configuration/application-roles.properties
>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>>>> standalone/configuration/logging.properties
>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>>>> standalone/configuration/mgmt-groups.properties
>>>>>
>>>>> Now, as you said, those files privileges are indeed fine-grained, so
>>>>> maybe we can push back to people making the RPM for them to NOT change the
>>>>> following files privileges:
>>>>>
>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>>>> appclient/configuration/logging.properties
>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>>>> domain/configuration/default-server-logging.properties
>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>>>> domain/configuration/logging.properties
>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>>>> standalone/configuration/logging.properties
>>>>>
>>>>> However, I don't see the value of letting those files accessible
>>>>> either group member or any user on the system, but maybe we can make the
>>>>> argument they should. But the write privileges for group member sounds
>>>>> wrong to me.
>>>>>
>>>>> Also, I'm puzzled Brian and I are seeing different things - am I
>>>>> looking at the correct zipfile here ?
>>>>>
>>>>> Note: You also mention the module.xml - as far as I can see from the
>>>>> diff provided with issue JBEAP-12374, I don't see any issue with privileges
>>>>> regarding those files, so we can remove them of the discussion. The only
>>>>> changes we need to discuss is removing the 'write' privileges' for the
>>>>> group on jars, reducing the scope of permissions on (some) folders, and
>>>>> privileges on (some) properties files. So, module.xml are out of the scope.
>>>>>
>>>>> On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry <
>>>>> brian.stansberry at redhat.com> wrote:
>>>>>
>>>>>> Seems I forgot to "Reply to All" yesterday. The following was meant
>>>>>> to be sent to wildfly-dev.
>>>>>>
>>>>>> On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry <
>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>
>>>>>>> Before getting into the specifics, first a general note re: perms.
>>>>>>>
>>>>>>> Our general permission set for is rwxr-xr-x for directories and
>>>>>>> rwxr--r-- for files. If someone thinks that's wrong in general; speak up.
>>>>>>> ;). Otherwise I think any deviation from that we should justify. Not that
>>>>>>> deviations are wrong, just that they need to have a reason.
>>>>>>>
>>>>>>> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <belaran at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Well, the diff is between the RPM and the zipfile is pretty long,
>>>>>>>> but it boils down to the 3 set of differences I've pointed out on
>>>>>>>> WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574>
>>>>>>>>
>>>>>>>>    - *.properties and .jar* files are associated with the mask
>>>>>>>>    rw-rw-r-- giving access to it to any other users and allowing group member
>>>>>>>>    to modify the file - the RPM distribution fixes that by removing the write
>>>>>>>>    privileges for the group (rw-r--r--). I personnaly don't see the value of
>>>>>>>>    letting the group members modify those files, I just can see how this could
>>>>>>>>    be exploited, so I would say it falls into "clearly wrong and not our
>>>>>>>>    intent". A case might be made for the .properties files, but for jars file
>>>>>>>>    I really don't see a valid use case (unless of course, any of you know one)
>>>>>>>>    ;
>>>>>>>>
>>>>>>>> There are a few different things here, so let's deal with them
>>>>>>> separately.
>>>>>>>
>>>>>>> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as
>>>>>>> rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I
>>>>>>> don't see why they should vary from the general standard. And the
>>>>>>> module.xml file should be consistent, since there's not much point in
>>>>>>> locking people from touching jars but letting them change what jars get
>>>>>>> loaded.
>>>>>>>
>>>>>>> For properties files, let's consider them on a more fine-grained
>>>>>>> basis. For example, the properties files used by the security realms have
>>>>>>> different kinds of data than logging.properties does.
>>>>>>>
>>>>>>> The perms on the security realm property files are rw-------, not
>>>>>>> rw-rw-r--.
>>>>>>>
>>>>>>> The logging.properties files are rw-r--r-- which is consistent with
>>>>>>> the domain|host|standalone.xml files and with the general standard.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>    -
>>>>>>>>    - *some directories* like 'domain/tmp/auth' have too
>>>>>>>>    restrictive mask like rwx------ and RPMS to turned them into rwxrwxr-x
>>>>>>>>    (that I don't really agree with) and
>>>>>>>>
>>>>>>>>
>>>>>>>>    - *other directories*, likes 'domain' have again a too
>>>>>>>>    permissive mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make
>>>>>>>>    senses.
>>>>>>>>
>>>>>>>> In the unzip I see these directories as rwxr-xr-x, which I think is
>>>>>>> fine.
>>>>>>>
>>>>>>> Are you concerned with any other directories besides
>>>>>>> $JBOSS_HOME/domain and $JBOSS_HOME/standalone?
>>>>>>>
>>>>>>>> So we need to find an agreement on those three items, and then see
>>>>>>>> how we proceed to implement the fix (if needed).
>>>>>>>>
>>>>>>>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry <
>>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> I think we need to start with the assumption that the permissions
>>>>>>>>> we have in the zip are the way they are for a reason and evaluate possible
>>>>>>>>> changes based on discussion here of each type of change. Maybe the RPM
>>>>>>>>> settings are better, maybe they are not. Or maybe they are better but the
>>>>>>>>> improvement is not worth the disruption a change may cause to our end
>>>>>>>>> users, who may rely on the current zip settings. Or maybe what we have in
>>>>>>>>> the zip is clearly wrong and doesn't follow our own intent. I expect we'll
>>>>>>>>> probably see a little of each category, although hopefully some changes for
>>>>>>>>> WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :)
>>>>>>>>>
>>>>>>>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <
>>>>>>>>> belaran at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> As reported on JBEAP-12374[1], there is some discrepancies
>>>>>>>>>> between the ZIP file we provided for Widlfy/EAP and the RPM generate. Most
>>>>>>>>>> of those discrepancies - or the most relevant ones, are some fine tuning
>>>>>>>>>> performed on the (POSIX) privileges (things such as removing the write
>>>>>>>>>> privilege for member of the same group as the owner of the file).
>>>>>>>>>>
>>>>>>>>>> I've looked into this and because those files are produced by our
>>>>>>>>>> own Maven plugin (as part of wildfly-build-tools), we can not simply modify
>>>>>>>>>> the assembly.xml. Which actually is probably for the best, as it would made
>>>>>>>>>> the assembly file quite cumbersome.
>>>>>>>>>>
>>>>>>>>>> Anyhow, I've worked on a proposal[2] for the wildfly-build-tools,
>>>>>>>>>> but when I reported the problem on WFLY-9574[3], Brian suggested I started
>>>>>>>>>> a discussion here. So does anyone have a (strong) opinion about this issue
>>>>>>>>>> and/or how to resolve it ? :)
>>>>>>>>>>
>>>>>>>>>> (For the record, I do think it is best to fix the privileges to
>>>>>>>>>> follow what the RPM does for us for now, but if you feel this issue should
>>>>>>>>>> not be addressed, and dev- the issue, I'm certainly not opposed to it
>>>>>>>>>> either).
>>>>>>>>>>
>>>>>>>>>> [1] https://issues.jboss.org/browse/JBEAP-12374
>>>>>>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40
>>>>>>>>>> [3] https://issues.jboss.org/browse/WFLY-9574
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Brian Stansberry
>>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>>> Red Hat
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Brian Stansberry
>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>> Red Hat
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Brian Stansberry
>>>>>> Manager, Senior Principal Software Engineer
>>>>>> Red Hat
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Manager, Senior Principal Software Engineer
>>>> Red Hat
>>>>
>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> Red Hat
>>>
>>
>>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171211/b4b267ff/attachment-0001.html 

From jdenise at redhat.com  Mon Dec 11 09:30:20 2017
From: jdenise at redhat.com (Jean-Francois Denise)
Date: Mon, 11 Dec 2017 15:30:20 +0100
Subject: [wildfly-dev] security/elytron CLI commands
In-Reply-To: <787d198f-242b-fc69-6903-50e32f23d402@redhat.com>
References: <7c8de310-84a7-6fae-01d6-484a453205bf@redhat.com>
	<CAPhbRDZbMDXKj--vK_vtFDgy2mQUnq_oTo114EwJ7XPDme9ehQ@mail.gmail.com>
	<787d198f-242b-fc69-6903-50e32f23d402@redhat.com>
Message-ID: <962bdb14-65d6-be15-4f57-886e0601b3d6@redhat.com>

FYI, some discussions have occurred with Martin and Farah. I have 
updated the document[1] and introduced a new document[2] to get feedback 
on CLI commands for SASL/HTTP authentication.

[1] https://developer.jboss.org/wiki/SSLCommandsForCLI

[2] https://developer.jboss.org/wiki/AuthenticationCommandsForCLI

Thanks.

JF

On 23/11/17 15:25, Jean-Francois Denise wrote:
>
> Farah, brought to my attention the key-store future operations[1] that 
> will allow to bypass keytool. With this, key-store management seems to 
> deserve its own set of "a la keytool" commands. I have updated the 
> document[2] to reflect the separation.
>
> JF
>
> [1] 
> https://developer.jboss.org/wiki/AnalysisDesign-AdvancedElytronKey-storeManipulationOperations
> [2] https://developer.jboss.org/wiki/SSLCommandsForCLI
>
> On 20/11/17 20:45, Brian Stansberry wrote:
>> +1 to discussing on the list.
>>
>> That sounds pretty good. You don't want to add things that will 
>> conflict with other things you might want to do later, but these 
>> actions sound quite targeted to their particular use case and have 
>> names that are also specific.
>>
>> On Fri, Nov 17, 2017 at 9:47 AM, Jean-Francois Denise 
>> <jdenise at redhat.com <mailto:jdenise at redhat.com>> wrote:
>>
>>     Hi,
>>
>>     discussing with Darran on how to extend the CLI to help configure
>>     elytron, he suggested that we should move the discussion to this
>>     list. I
>>     have started a document [1] in order to collect feedbacks on new CLI
>>     commands to address security configuration. Feel free to comment
>>     on the
>>     document.
>>     Thank-you.
>>     JF
>>     [1] https://developer.jboss.org/wiki/SSLCommandsForCLI
>>     <https://developer.jboss.org/wiki/SSLCommandsForCLI>
>>     _______________________________________________
>>     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
>>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>>
>>
>>
>>
>> -- 
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171211/732d0415/attachment.html 

From jperkins at redhat.com  Mon Dec 11 12:11:00 2017
From: jperkins at redhat.com (James Perkins)
Date: Mon, 11 Dec 2017 09:11:00 -0800
Subject: [wildfly-dev] Logging Changes
In-Reply-To: <CANghgrRrbV_ksi8FBOSQthc1XLsVrc-sNyBGz69tJFgD00GFiQ@mail.gmail.com>
References: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
	<CANghgrRrbV_ksi8FBOSQthc1XLsVrc-sNyBGz69tJFgD00GFiQ@mail.gmail.com>
Message-ID: <CADGwLpispdm=eVuGmqgZ6LbEUyH-LymZ63G=ef_Z3kPsdJV_Mg@mail.gmail.com>

We could easily just allow the system property to be changed for the caller
calculation. It would be fairly simple really.

Any hack would likely have to be done in the scripts would be my concern.
I'm sure it's possible, but I'd rather not be messing with scripts if
possible. Though maybe there is a way with a custom ConfigurationLocator.
I'll have a look at that approach.

On Thu, Dec 7, 2017 at 3:46 PM, David Lloyd <david.lloyd at redhat.com> wrote:

> On Thu, Dec 7, 2017 at 2:02 PM, James Perkins <jperkins at redhat.com> wrote:
> > There will be a slight performance impact during boot. This can be
> greatly
> > reduced if the caller calculation is disabled. This can be done in normal
> > cases, but we likely can't make it the default.
>
> I suspect we can safely disable caller calculation by default on boot,
> as long as users have an easy way to turn it on.
>
> Also I think we should consider some kind of grimy hack to bootstrap
> the logging subsystem first, if it's present, otherwise immediately
> fall back to properties-based config if it's absent.
>
> --
> - DML
>



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

From jperkins at redhat.com  Mon Dec 11 12:23:35 2017
From: jperkins at redhat.com (James Perkins)
Date: Mon, 11 Dec 2017 09:23:35 -0800
Subject: [wildfly-dev] Logging Changes
In-Reply-To: <CABSyOEFUC2hJ-torQWnRbXUAcuzhfmrTP+7vu0rwa3E1Mfmgbg@mail.gmail.com>
References: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
	<CABSyOEFUC2hJ-torQWnRbXUAcuzhfmrTP+7vu0rwa3E1Mfmgbg@mail.gmail.com>
Message-ID: <CADGwLphoT7BRSks0AZCLmCvM62qFikS5jFs3ajZuDhm1ipQU0A@mail.gmail.com>

That JEP unfortunately won't really help us here. The idea with that is the
JDK itself, likely some tooling too, would just use a System.Logger which
could be any logging implementation. It's not really meant to bootstrap
anything it's just meant as a facade really. So if you wrote
System.LoggerFinder implementation for log4j the JDK itself would log
through log4j using the System.Logger.

I did experiment creating a JBoss Logging System.LoggerFinder, but I don't
see much use in it as this point since we essentially use JUL which is the
default finder. However if we do get to a point where we want the log
manager in WildFly to be easily replaceable it may make since to have a
System.LoggerFinder implementation.

On Fri, Dec 8, 2017 at 2:47 AM, Richard Opalka <ropalka at redhat.com> wrote:

> Hi James (all),
>
>    What you outlined above is similar to effort [1] that was done for JDK
> 9.
> Are there are any plans integrating this effort somehow with JDK9 or
> better
> reuse what JDK9 already provides?
>    I was doing some research few months back (but I didn't finish it yet)
> how
> logging is done in JDK9. I was hoping for better JBoss-Logging integration
> with JDK9 logging.
>    Although I didn't finish it yet I'm posting here few analysis documents
> I have created so far. I hope they will be helpful.
>
> Rio
>
> [1] http://openjdk.java.net/jeps/158
>
>
> On Thu, Dec 7, 2017 at 9:02 PM, James Perkins <jperkins at redhat.com> wrote:
>
>> Hello All,
>> For WildFly 12 (maybe not until 13 at this stage) there are some thoughts
>> on significantly changing the way logging is configured. Currently logging
>> is initialized by reading a logging.properties file when JBoss Modules
>> boots. While this works okay there are a few issues with this approach.
>>
>>
>>    1. For boot logging (before the logging subsystem is initialized) you
>>    can't use property expressions. This means when the logging subsystem
>>    rewrites the logging.properties file with all expressions expanded.
>>    2. Logging objects, such as handlers, cannot use resources from other
>>    subsystems. For example there is a need for a socket-handler. With the
>>    socket handler we need a way to get an SSL context from Elytron. There is
>>    no way for this to be done using a logging.properties file for the boot log
>>    configuration.
>>    3. If the user want to manually change the logging configuration by
>>    editing the XML they also have to edit the logging.properties. If not the
>>    old configuration will be used until the next boot.
>>
>> It would be useful to introduce a way to queue log messages during boot
>> [1]. Once the logging subsystem boot is complete the messages would be
>> drained and sent to the new configuration. This of course isn't without
>> it's own issues.
>>
>>
>>    1. Messages appeared delayed when WildFly is booting. Essentially all
>>    the boot messages are written at once so you see no messages, then all of
>>    them at once.
>>    2. A shutdown hook would have to be used in order to ensure errors
>>    that cause a boot failure are logged.
>>    3. This could get a little tricky with offline CLI as currently
>>    logging is configured based on the logging.properties file
>>    4. If users remove the logging subsystem there are more steps than
>>    just removing logging subsystem to get logging working.
>>    5. There will be a slight performance impact during boot. This can be
>>    greatly reduced if the caller calculation is disabled. This can be done in
>>    normal cases, but we likely can't make it the default. Note too this is
>>    only a boot impact. Once the logging subsystem takes over, the performance
>>    should be exactly the same as it was before.
>>
>> There is some good however too. This does open the door allowing users to
>> more easily replace the log manager implementation for standalone servers.
>> Currently we still, and maybe always will, require the JBoss Log Manager to
>> be used for domain servers, the host controller and process controller.
>>
>> It also removes the need for a logging.properties for servers. I think
>> this is a big bonus to the changes as logging for servers will only be
>> configured in one place now. Domain will be a bit different, but we should
>> likely introduce a logging subsystem on the host controller as well. I just
>> don't think it makes much sense until we can sort out the issues above.
>>
>> The current idea is that boot logging will be configurable via system
>> properties. These properties would have to be set in the JAVA_OPTS.
>>
>> I'm curious to hear any concerns others might have about this. This feels
>> like a rather significant change so I'd rather get it right the first time.
>>
>> I have started a design doc, but it's not finalized yet. If you're
>> curious however you can have at look at it on my topic branch [2]. You can
>> also see some of the small changes I've made to get it working on WildFly
>> Core on that branch.
>>
>>
>> [1]: https://issues.jboss.org/browse/LOGMGR-177
>> [2]: https://github.com/jamezp/wildfly-core/blob/bootstrap-
>> logging/logging/bootstrap-logging.asciidoc
>>
>> --
>> 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
>>
>
>
>
> --
> --
> Richard Opalka
> Principal Software Engineer
> Red Hat JBoss Middleware
> Mobile: +420 731 186 942 <+420%20731%20186%20942>
> E-mail: ropalka at redhat.com
>
>


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

From jperkins at redhat.com  Mon Dec 11 17:28:48 2017
From: jperkins at redhat.com (James Perkins)
Date: Mon, 11 Dec 2017 14:28:48 -0800
Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have
 POSIX permissions perfectly set
In-Reply-To: <CALuBA_pfzAOsZf_fU=sN6uGkCdm04iwAwxJyV4r4gEkupSp2HQ@mail.gmail.com>
References: <CALuBA_p5Mqag2+TSD9bUWGM5BgDpirdZC7zvL5OE8w-HfA4AWw@mail.gmail.com>
	<CAPhbRDYyGwNpqFq8bYdRk53_hx6Mg4yHwOcmmYYnwDp_3-B+_A@mail.gmail.com>
	<CALuBA_pSvfNYPug1byQrS7Bic45vVvvdQ4Mjd-BQ6Pa4t5m05g@mail.gmail.com>
	<CAPhbRDYnYLd-SXuE_m_2b14W9VwNhy08KDpC0MdP6n3mipMi0A@mail.gmail.com>
	<CAPhbRDZFTd52gO8-psaaXJSVNAPn=3MtjA3XuyEC501Hj-rRJw@mail.gmail.com>
	<CALuBA_pXT89PNspojT-sT3GNTVhf1R1F7YJPxn7K-B6dmP4+bg@mail.gmail.com>
	<CAPhbRDZFfcuS5kZNHU99cVDSTjewsVynuaZAAxsxdQSswxOZOA@mail.gmail.com>
	<CAPhbRDYN_PGP8fo6BizQ3EOR-=9UT_jrJEECzLBfT-DoOt05fg@mail.gmail.com>
	<CALuBA_qxu=nGP93yfPXEdhiUdxBkQ2C7YZx=82i7qbOA=egr+A@mail.gmail.com>
	<CAPhbRDZAnSLP6OYkWUHkvczj-sm4FGaE6apEEoiGRo_D+Z=nww@mail.gmail.com>
	<CALuBA_pfzAOsZf_fU=sN6uGkCdm04iwAwxJyV4r4gEkupSp2HQ@mail.gmail.com>
Message-ID: <CADGwLphZ9wWbLh87qrDihpeFzKumGFnkabcq1FzwkWSTRrE6vA@mail.gmail.com>

I personally don't have any strong opinions on what the permissions should
be. However as I said before it should definitely not be the provisioning
plugin that sets these permissions. If they need to be different we need to
change them in the feature pack.

On Mon, Dec 11, 2017 at 4:47 AM, Romain Pelisse <belaran at redhat.com> wrote:

> Hi all,
>
> Not too much involvement except from Brian and I :) - sadly, we cannot
> move forward on this topic without a minimum of consensus. If you don't to
> participate, can you at least reply "+1 Brian" (if you think we should NOT
> try to change the current behavior") or "+1 Romain" (if you think we should
> address this issue somehow).
>
> (please don't vote on the PR I've proposed, it's just a proposal on HOW we
> could do it - here I want to assert IF we want to do it, not voting on the
> "how").
>
> On Wed, Dec 6, 2017 at 6:05 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>> On Wed, Dec 6, 2017 at 4:27 AM, Romain Pelisse <belaran at redhat.com>
>> wrote:
>>
>>> Hi Brian (and all),
>>>
>>> I honestly understand your resistance, and I'm completely fine if we end
>>> up closing this all issue as WONTDO or REJECTED. I just do want to have a
>>> discussion about it and come back with clear reasons and motivations for
>>> changing or not the privileges of each of those files.
>>>
>>
>> Thanks for doing this! There have been a number of issues filed over the
>> last year or so on this general topic so I'm very happy to see them getting
>> addressed here via the WildFly community. Most of the issues I've been
>> talking about are JBEAP issues in JIRA, which is fine, but the best way to
>> get this solid is to get WildFly the way we want it first.
>>
>> Even on the config file read perms thing I mentioned in my last post, I'm
>> personally resistant to changing it, but my biggest resistance is to doing
>> that without a full community discussion.
>>
>>
>>> Given that we see different things on our local setup, I think the best
>>> will be to use a build on a CI Server and works from what we see there. Is
>>> there an easy way for me to clone a job building Wildfly and tweak it on
>>> some (publicly) accessible instance ?
>>>
>>
>> https://developer.jboss.org/thread/224262 describes how to get a zip
>> built from a daily CI job.
>>
>> If anyone has any insights on this, please speak up!
>>
>>
>>>
>>>
>>> On Mon, Dec 4, 2017 at 6:48 PM, Brian Stansberry <
>>> brian.stansberry at redhat.com> wrote:
>>>
>>>> A slightly different topic, related to the "logging.properties/xml
>>>> config file" topic is whether these files should be world and/or group
>>>> readable.
>>>>
>>>> Changing this has been proposed in the past on the EAP side, primarily
>>>> based on the argument that users could put sensitive data in these files.
>>>> This thread seems like a good time to debate this a bit in community.
>>>>
>>>> I've resisted that primarily on the basis of:
>>>>
>>>> 1) These files or those similarly used have had these perms as far back
>>>> as I can find in JBoss AS. So the odds that some people are relying upon
>>>> those perms is fairly high and we need to assume a change would be a
>>>> breaking change for some people.
>>>>
>>>> 2) Other software I've looked at like Tomcat and httpd have similar
>>>> permission schemes to what we have for their config files, which can also
>>>> potentially include sensitive data.
>>>>
>>>> 3) We provide facilities like the vault or elytron credential store
>>>> refs for keeping sensitive data out of the config files.
>>>>
>>>>
>>>> On Mon, Dec 4, 2017 at 11:38 AM, Brian Stansberry <
>>>> brian.stansberry at redhat.com> wrote:
>>>>
>>>>> Thanks, Romain.
>>>>>
>>>>> Re: what the actual permissions are, FWIW I get what I see on both my
>>>>> macbook and my Fedora 27 machine, both when unzipping the actual
>>>>> 11.0.0.Final and when unzipping the result of a build of master, and both
>>>>> with and without the -Prelease -Pjboss-release args to maven that we
>>>>> include when doing actual releases. Unzipping the zip in build/target
>>>>> doesn't include the jars of course.
>>>>>
>>>>> So it sounds like we need input from others.
>>>>>
>>>>> Re: modules.xml, if you are seeing those as rw-r--r-- as well, then +1
>>>>> to ignoring them in further discussion.
>>>>>
>>>>> Re: logging.properties, those serve a very similar conceptual role to
>>>>> the standalone|host|domain.xml files so I see no reason for them to have
>>>>> different perms. However, you and I are getting different results, where
>>>>> you report them as group writable and I don't. What do you see for the xml
>>>>> config files?
>>>>>
>>>>> Re: RPM changing to match WildFly, that's an EAP discussion, so that
>>>>> can be taken up elsewhere once we have WildFly the way we want it.
>>>>>
>>>>>
>>>>> On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse <belaran at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Brian and all,
>>>>>>
>>>>>> err, my own observation differs from yours. I've rebuild Wildfly from
>>>>>> the last content of the master branch and get the same privileges on the
>>>>>> jboss-modules.jar (so -rw-rw-r-- and not as you are seeing  rwxr--r--).
>>>>>> Same with the domain folder, which turns out on my local system associated
>>>>>> to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a
>>>>>> transcript of what I did - maybe you can spot why our results differs so
>>>>>> much.
>>>>>>
>>>>>> $ git show
>>>>>> commit 46e119c65d9e32bc0ec69f3933267fece959ed3f
>>>>>> Merge: 051f080 c7d9075
>>>>>> Author: Kabir Khan <kkhan at redhat.com>
>>>>>> Date:   Tue Nov 28 17:46:40 2017 +0000
>>>>>>
>>>>>>     Merge pull request #10669 from praxeo/WFLY-9284
>>>>>>
>>>>>>     WFLY-9284 Correct MVN env variable to mvnw.cmd
>>>>>>
>>>>>> $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d
>>>>>> wildfly-12.zip
>>>>>> ...
>>>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.
>>>>>> jar
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov.  11:41
>>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
>>>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/  -d
>>>>>> drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov.  11:41
>>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/
>>>>>>
>>>>>> Checking all the jars in the distribution, they all appears to have
>>>>>> the mask '-rw-rw-r--':
>>>>>>
>>>>>> $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done |
>>>>>> sed -e '/-rw-rw-r--/d'
>>>>>> $
>>>>>>
>>>>>> Regarding properties files, here is the exhaustive list of properties
>>>>>> that RPM packaging has modified the privileges of:
>>>>>>
>>>>>> appclient/configuration/logging.properties rw-------
>>>>>> domain/configuration/application-roles.properties rw-------
>>>>>> domain/configuration/default-server-logging.properties rw-------
>>>>>> domain/configuration/logging.properties rw-------
>>>>>> domain/configuration/mgmt-groups.properties rw-------
>>>>>> standalone/configuration/application-roles.properties rw-------
>>>>>> standalone/configuration/logging.properties rw-------
>>>>>> standalone/configuration/mgmt-groups.properties rw-------
>>>>>>
>>>>>> If I compare that with the content of the extract zip (same fresh
>>>>>> built as above), I can see that 4 files are not having the same mask
>>>>>> (rw------):
>>>>>>
>>>>>> $ for file in $(cut -f1 -d\  ../../../list-props-files.txt ); do ls
>>>>>> -l $file ; done
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>>>>> appclient/configuration/logging.properties
>>>>>> -rw-------. 1 rpelisse rpelisse 710 30 nov.  11:41
>>>>>> domain/configuration/application-roles.properties
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>>>>> domain/configuration/default-server-logging.properties
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>>>>> domain/configuration/logging.properties
>>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>>>>> domain/configuration/mgmt-groups.properties
>>>>>> -rw-------. 1 rpelisse rpelisse 711 30 nov.  11:41
>>>>>> standalone/configuration/application-roles.properties
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>>>>> standalone/configuration/logging.properties
>>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>>>>> standalone/configuration/mgmt-groups.properties
>>>>>>
>>>>>> Now, as you said, those files privileges are indeed fine-grained, so
>>>>>> maybe we can push back to people making the RPM for them to NOT change the
>>>>>> following files privileges:
>>>>>>
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>>>>> appclient/configuration/logging.properties
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>>>>> domain/configuration/default-server-logging.properties
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>>>>> domain/configuration/logging.properties
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>>>>> standalone/configuration/logging.properties
>>>>>>
>>>>>> However, I don't see the value of letting those files accessible
>>>>>> either group member or any user on the system, but maybe we can make the
>>>>>> argument they should. But the write privileges for group member sounds
>>>>>> wrong to me.
>>>>>>
>>>>>> Also, I'm puzzled Brian and I are seeing different things - am I
>>>>>> looking at the correct zipfile here ?
>>>>>>
>>>>>> Note: You also mention the module.xml - as far as I can see from the
>>>>>> diff provided with issue JBEAP-12374, I don't see any issue with privileges
>>>>>> regarding those files, so we can remove them of the discussion. The only
>>>>>> changes we need to discuss is removing the 'write' privileges' for the
>>>>>> group on jars, reducing the scope of permissions on (some) folders, and
>>>>>> privileges on (some) properties files. So, module.xml are out of the scope.
>>>>>>
>>>>>> On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry <
>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>
>>>>>>> Seems I forgot to "Reply to All" yesterday. The following was meant
>>>>>>> to be sent to wildfly-dev.
>>>>>>>
>>>>>>> On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry <
>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>
>>>>>>>> Before getting into the specifics, first a general note re: perms.
>>>>>>>>
>>>>>>>> Our general permission set for is rwxr-xr-x for directories and
>>>>>>>> rwxr--r-- for files. If someone thinks that's wrong in general; speak up.
>>>>>>>> ;). Otherwise I think any deviation from that we should justify. Not that
>>>>>>>> deviations are wrong, just that they need to have a reason.
>>>>>>>>
>>>>>>>> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <belaran at redhat.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Well, the diff is between the RPM and the zipfile is pretty long,
>>>>>>>>> but it boils down to the 3 set of differences I've pointed out on
>>>>>>>>> WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574>
>>>>>>>>>
>>>>>>>>>    - *.properties and .jar* files are associated with the mask
>>>>>>>>>    rw-rw-r-- giving access to it to any other users and allowing group member
>>>>>>>>>    to modify the file - the RPM distribution fixes that by removing the write
>>>>>>>>>    privileges for the group (rw-r--r--). I personnaly don't see the value of
>>>>>>>>>    letting the group members modify those files, I just can see how this could
>>>>>>>>>    be exploited, so I would say it falls into "clearly wrong and not our
>>>>>>>>>    intent". A case might be made for the .properties files, but for jars file
>>>>>>>>>    I really don't see a valid use case (unless of course, any of you know one)
>>>>>>>>>    ;
>>>>>>>>>
>>>>>>>>> There are a few different things here, so let's deal with them
>>>>>>>> separately.
>>>>>>>>
>>>>>>>> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as
>>>>>>>> rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I
>>>>>>>> don't see why they should vary from the general standard. And the
>>>>>>>> module.xml file should be consistent, since there's not much point in
>>>>>>>> locking people from touching jars but letting them change what jars get
>>>>>>>> loaded.
>>>>>>>>
>>>>>>>> For properties files, let's consider them on a more fine-grained
>>>>>>>> basis. For example, the properties files used by the security realms have
>>>>>>>> different kinds of data than logging.properties does.
>>>>>>>>
>>>>>>>> The perms on the security realm property files are rw-------, not
>>>>>>>> rw-rw-r--.
>>>>>>>>
>>>>>>>> The logging.properties files are rw-r--r-- which is consistent with
>>>>>>>> the domain|host|standalone.xml files and with the general standard.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>    -
>>>>>>>>>    - *some directories* like 'domain/tmp/auth' have too
>>>>>>>>>    restrictive mask like rwx------ and RPMS to turned them into rwxrwxr-x
>>>>>>>>>    (that I don't really agree with) and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    - *other directories*, likes 'domain' have again a too
>>>>>>>>>    permissive mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make
>>>>>>>>>    senses.
>>>>>>>>>
>>>>>>>>> In the unzip I see these directories as rwxr-xr-x, which I think
>>>>>>>> is fine.
>>>>>>>>
>>>>>>>> Are you concerned with any other directories besides
>>>>>>>> $JBOSS_HOME/domain and $JBOSS_HOME/standalone?
>>>>>>>>
>>>>>>>>> So we need to find an agreement on those three items, and then see
>>>>>>>>> how we proceed to implement the fix (if needed).
>>>>>>>>>
>>>>>>>>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry <
>>>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> I think we need to start with the assumption that the permissions
>>>>>>>>>> we have in the zip are the way they are for a reason and evaluate possible
>>>>>>>>>> changes based on discussion here of each type of change. Maybe the RPM
>>>>>>>>>> settings are better, maybe they are not. Or maybe they are better but the
>>>>>>>>>> improvement is not worth the disruption a change may cause to our end
>>>>>>>>>> users, who may rely on the current zip settings. Or maybe what we have in
>>>>>>>>>> the zip is clearly wrong and doesn't follow our own intent. I expect we'll
>>>>>>>>>> probably see a little of each category, although hopefully some changes for
>>>>>>>>>> WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :)
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <
>>>>>>>>>> belaran at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> As reported on JBEAP-12374[1], there is some discrepancies
>>>>>>>>>>> between the ZIP file we provided for Widlfy/EAP and the RPM generate. Most
>>>>>>>>>>> of those discrepancies - or the most relevant ones, are some fine tuning
>>>>>>>>>>> performed on the (POSIX) privileges (things such as removing the write
>>>>>>>>>>> privilege for member of the same group as the owner of the file).
>>>>>>>>>>>
>>>>>>>>>>> I've looked into this and because those files are produced by
>>>>>>>>>>> our own Maven plugin (as part of wildfly-build-tools), we can not simply
>>>>>>>>>>> modify the assembly.xml. Which actually is probably for the best, as it
>>>>>>>>>>> would made the assembly file quite cumbersome.
>>>>>>>>>>>
>>>>>>>>>>> Anyhow, I've worked on a proposal[2] for the
>>>>>>>>>>> wildfly-build-tools, but when I reported the problem on WFLY-9574[3], Brian
>>>>>>>>>>> suggested I started a discussion here. So does anyone have a (strong)
>>>>>>>>>>> opinion about this issue and/or how to resolve it ? :)
>>>>>>>>>>>
>>>>>>>>>>> (For the record, I do think it is best to fix the privileges to
>>>>>>>>>>> follow what the RPM does for us for now, but if you feel this issue should
>>>>>>>>>>> not be addressed, and dev- the issue, I'm certainly not opposed to it
>>>>>>>>>>> either).
>>>>>>>>>>>
>>>>>>>>>>> [1] https://issues.jboss.org/browse/JBEAP-12374
>>>>>>>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40
>>>>>>>>>>> [3] https://issues.jboss.org/browse/WFLY-9574
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Brian Stansberry
>>>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>>>> Red Hat
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Brian Stansberry
>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>> Red Hat
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Brian Stansberry
>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>> Red Hat
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Manager, Senior Principal Software Engineer
>>>>> Red Hat
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Manager, Senior Principal Software Engineer
>>>> Red Hat
>>>>
>>>
>>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>>
>
>
> _______________________________________________
> 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/20171211/2a300c1b/attachment-0001.html 

From cdewolf at redhat.com  Tue Dec 12 03:20:13 2017
From: cdewolf at redhat.com (Carlo de Wolf)
Date: Tue, 12 Dec 2017 09:20:13 +0100
Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have
 POSIX permissions perfectly set
In-Reply-To: <CADGwLphZ9wWbLh87qrDihpeFzKumGFnkabcq1FzwkWSTRrE6vA@mail.gmail.com>
References: <CALuBA_p5Mqag2+TSD9bUWGM5BgDpirdZC7zvL5OE8w-HfA4AWw@mail.gmail.com>
	<CAPhbRDYyGwNpqFq8bYdRk53_hx6Mg4yHwOcmmYYnwDp_3-B+_A@mail.gmail.com>
	<CALuBA_pSvfNYPug1byQrS7Bic45vVvvdQ4Mjd-BQ6Pa4t5m05g@mail.gmail.com>
	<CAPhbRDYnYLd-SXuE_m_2b14W9VwNhy08KDpC0MdP6n3mipMi0A@mail.gmail.com>
	<CAPhbRDZFTd52gO8-psaaXJSVNAPn=3MtjA3XuyEC501Hj-rRJw@mail.gmail.com>
	<CALuBA_pXT89PNspojT-sT3GNTVhf1R1F7YJPxn7K-B6dmP4+bg@mail.gmail.com>
	<CAPhbRDZFfcuS5kZNHU99cVDSTjewsVynuaZAAxsxdQSswxOZOA@mail.gmail.com>
	<CAPhbRDYN_PGP8fo6BizQ3EOR-=9UT_jrJEECzLBfT-DoOt05fg@mail.gmail.com>
	<CALuBA_qxu=nGP93yfPXEdhiUdxBkQ2C7YZx=82i7qbOA=egr+A@mail.gmail.com>
	<CAPhbRDZAnSLP6OYkWUHkvczj-sm4FGaE6apEEoiGRo_D+Z=nww@mail.gmail.com>
	<CALuBA_pfzAOsZf_fU=sN6uGkCdm04iwAwxJyV4r4gEkupSp2HQ@mail.gmail.com>
	<CADGwLphZ9wWbLh87qrDihpeFzKumGFnkabcq1FzwkWSTRrE6vA@mail.gmail.com>
Message-ID: <0ec575db-fa44-dd31-73a6-766ec0edc7a8@redhat.com>

If any target platform needs more restrictive permissions, those need to 
apply to all deliverables (whether it is ZIP or RPMs).

Carlo

On 11-12-17 23:28, James Perkins wrote:
> I personally don't have any strong opinions on what the permissions 
> should be. However as I said before it should definitely not be the 
> provisioning plugin that sets these permissions. If they need to be 
> different we need to change them in the feature pack.
>
> On Mon, Dec 11, 2017 at 4:47 AM, Romain Pelisse <belaran at redhat.com 
> <mailto:belaran at redhat.com>> wrote:
>
>     Hi all,
>
>     Not too much involvement except from Brian and I :) - sadly, we
>     cannot move forward on this topic without a minimum of consensus.
>     If you don't to participate, can you at least reply "+1 Brian" (if
>     you think we should NOT try to change the current behavior") or
>     "+1 Romain" (if you think we should address this issue somehow).
>
>     (please don't vote on the PR I've proposed, it's just a proposal
>     on HOW we could do it - here I want to assert IF we want to do it,
>     not voting on the "how").
>
>     On Wed, Dec 6, 2017 at 6:05 PM, Brian Stansberry
>     <brian.stansberry at redhat.com <mailto:brian.stansberry at redhat.com>>
>     wrote:
>
>         On Wed, Dec 6, 2017 at 4:27 AM, Romain Pelisse
>         <belaran at redhat.com <mailto:belaran at redhat.com>> wrote:
>
>             Hi Brian (and all),
>
>             I honestly understand your resistance, and I'm completely
>             fine if we end up closing this all issue as WONTDO or
>             REJECTED. I just do want to have a discussion about it and
>             come back with clear reasons and motivations for changing
>             or not the privileges of each of those files.
>
>
>         Thanks for doing this! There have been a number of issues
>         filed over the last year or so on this general topic so I'm
>         very happy to see them getting addressed here via the WildFly
>         community. Most of the issues I've been talking about are
>         JBEAP issues in JIRA, which is fine, but the best way to get
>         this solid is to get WildFly the way we want it first.
>
>         Even on the config file read perms thing I mentioned in my
>         last post, I'm personally resistant to changing it, but my
>         biggest resistance is to doing that without a full community
>         discussion.
>
>
>             Given that we see different things on our local setup, I
>             think the best will be to use a build on a CI Server and
>             works from what we see there. Is there an easy way for me
>             to clone a job building Wildfly and tweak it on some
>             (publicly) accessible instance ?
>
>
>         https://developer.jboss.org/thread/224262
>         <https://developer.jboss.org/thread/224262> describes how to
>         get a zip built from a daily CI job.
>
>         If anyone has any insights on this, please speak up!
>
>
>
>             On Mon, Dec 4, 2017 at 6:48 PM, Brian Stansberry
>             <brian.stansberry at redhat.com
>             <mailto:brian.stansberry at redhat.com>> wrote:
>
>                 A slightly different topic, related to the
>                 "logging.properties/xml config file" topic is whether
>                 these files should be world and/or group readable.
>
>                 Changing this has been proposed in the past on the EAP
>                 side, primarily based on the argument that users could
>                 put sensitive data in these files. This thread seems
>                 like a good time to debate this a bit in community.
>
>                 I've resisted that primarily on the basis of:
>
>                 1) These files or those similarly used have had these
>                 perms as far back as I can find in JBoss AS. So the
>                 odds that some people are relying upon those perms is
>                 fairly high and we need to assume a change would be a
>                 breaking change for some people.
>
>                 2) Other software I've looked at like Tomcat and httpd
>                 have similar permission schemes to what we have for
>                 their config files, which can also potentially include
>                 sensitive data.
>
>                 3) We provide facilities like the vault or elytron
>                 credential store refs for keeping sensitive data out
>                 of the config files.
>
>                 On Mon, Dec 4, 2017 at 11:38 AM, Brian Stansberry
>                 <brian.stansberry at redhat.com
>                 <mailto:brian.stansberry at redhat.com>> wrote:
>
>                     Thanks, Romain.
>
>                     Re: what the actual permissions are, FWIW I get
>                     what I see on both my macbook and my Fedora 27
>                     machine, both when unzipping the actual
>                     11.0.0.Final and when unzipping the result of a
>                     build of master, and both with and without the
>                     -Prelease -Pjboss-release args to maven that we
>                     include when doing actual releases. Unzipping the
>                     zip in build/target doesn't include the jars of
>                     course.
>
>                     So it sounds like we need input from others.
>
>                     Re: modules.xml, if you are seeing those as
>                     rw-r--r-- as well, then +1 to ignoring them in
>                     further discussion.
>
>                     Re: logging.properties, those serve a very similar
>                     conceptual role to the standalone|host|domain.xml
>                     files so I see no reason for them to have
>                     different perms. However, you and I are getting
>                     different results, where you report them as group
>                     writable and I don't. What do you see for the xml
>                     config files?
>
>                     Re: RPM changing to match WildFly, that's an EAP
>                     discussion, so that can be taken up elsewhere once
>                     we have WildFly the way we want it.
>
>
>                     On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse
>                     <belaran at redhat.com <mailto:belaran at redhat.com>>
>                     wrote:
>
>                         Hi Brian and all,
>
>                         err, my own observation differs from yours.
>                         I've rebuild Wildfly from the last content of
>                         the master branch and get the same privileges
>                         on the jboss-modules.jar (so -rw-rw-r-- and
>                         not as you are seeing rwxr--r--). Same with
>                         the domain folder, which turns out on my local
>                         system associated to 'drwxrwxr-x.' and not
>                         'rwxr-xr-x' as you are seeing). See below for
>                         a transcript of what I did - maybe you can
>                         spot why our results differs so much.
>
>                         $ git show
>                         commit 46e119c65d9e32bc0ec69f3933267fece959ed3f
>                         Merge: 051f080 c7d9075
>                         Author: Kabir Khan <kkhan at redhat.com
>                         <mailto:kkhan at redhat.com>>
>                         Date:?? Tue Nov 28 17:46:40 2017 +0000
>
>                         ??? Merge pull request #10669 from
>                         praxeo/WFLY-9284
>
>                         ??? WFLY-9284 Correct MVN env variable to mvnw.cmd
>
>                         $ unzip
>                         ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip
>                         -d wildfly-12.zip
>                         ...
>                         $ ls -l
>                         wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
>                         -rw-rw-r--. 1 rpelisse rpelisse 403683 30
>                         nov.? 11:41
>                         wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
>                         $ ls -l
>                         wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/
>                         -d
>                         drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov.?
>                         11:41
>                         wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/
>
>                         Checking all the jars in the distribution,
>                         they all appears to have the mask '-rw-rw-r--':
>
>                         $ for jar in $(find dist/ -name *.jar); do ls
>                         -l "${jar}" ; done | sed -e '/-rw-rw-r--/d'
>                         $
>
>                         Regarding properties files, here is the
>                         exhaustive list of properties that RPM
>                         packaging has modified the privileges of:
>
>                         appclient/configuration/logging.properties
>                         rw-------
>                         domain/configuration/application-roles.properties
>                         rw-------
>                         domain/configuration/default-server-logging.properties
>                         rw-------
>                         domain/configuration/logging.properties rw-------
>                         domain/configuration/mgmt-groups.properties
>                         rw-------
>                         standalone/configuration/application-roles.properties
>                         rw-------
>                         standalone/configuration/logging.properties
>                         rw-------
>                         standalone/configuration/mgmt-groups.properties
>                         rw-------
>
>                         If I compare that with the content of the
>                         extract zip (same fresh built as above), I can
>                         see that 4 files are not having the same mask
>                         (rw------):
>
>                         $ for file in $(cut -f1 -d\
>                         ../../../list-props-files.txt ); do ls -l
>                         $file ; done
>                         -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.?
>                         11:41 appclient/configuration/logging.properties
>                         -rw-------. 1 rpelisse rpelisse 710 30 nov.?
>                         11:41
>                         domain/configuration/application-roles.properties
>                         -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.?
>                         11:41
>                         domain/configuration/default-server-logging.properties
>                         -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.?
>                         11:41 domain/configuration/logging.properties
>                         -rw-------. 1 rpelisse rpelisse 669 30 nov.?
>                         11:41 domain/configuration/mgmt-groups.properties
>                         -rw-------. 1 rpelisse rpelisse 711 30 nov.?
>                         11:41
>                         standalone/configuration/application-roles.properties
>                         -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.?
>                         11:41 standalone/configuration/logging.properties
>                         -rw-------. 1 rpelisse rpelisse 669 30 nov.?
>                         11:41
>                         standalone/configuration/mgmt-groups.properties
>
>                         Now, as you said, those files privileges are
>                         indeed fine-grained, so maybe we can push back
>                         to people making the RPM for them to NOT
>                         change the following files privileges:
>
>                         -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.?
>                         11:41 appclient/configuration/logging.properties
>                         -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.?
>                         11:41
>                         domain/configuration/default-server-logging.properties
>                         -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.?
>                         11:41 domain/configuration/logging.properties
>                         -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.?
>                         11:41 standalone/configuration/logging.properties
>
>                         However, I don't see the value of letting
>                         those files accessible either group member or
>                         any user on the system, but maybe we can make
>                         the argument they should. But the write
>                         privileges for group member sounds wrong to me.
>
>                         Also, I'm puzzled Brian and I are seeing
>                         different things - am I looking at the correct
>                         zipfile here ?
>
>                         Note: You also mention the module.xml - as far
>                         as I can see from the diff provided with issue
>                         JBEAP-12374, I don't see any issue with
>                         privileges regarding those files, so we can
>                         remove them of the discussion. The only
>                         changes we need to discuss is removing the
>                         'write' privileges' for the group on jars,
>                         reducing the scope of permissions on (some)
>                         folders, and privileges on (some) properties
>                         files. So, module.xml are out of the scope.
>
>                         On Thu, Nov 30, 2017 at 7:17 PM, Brian
>                         Stansberry <brian.stansberry at redhat.com
>                         <mailto:brian.stansberry at redhat.com>> wrote:
>
>                             Seems I forgot to "Reply to All"
>                             yesterday. The following was meant to be
>                             sent to wildfly-dev.
>
>                             On Wed, Nov 29, 2017 at 10:04 AM, Brian
>                             Stansberry <brian.stansberry at redhat.com
>                             <mailto:brian.stansberry at redhat.com>> wrote:
>
>                                 Before getting into the specifics,
>                                 first a general note re: perms.
>
>                                 Our general permission set for is
>                                 rwxr-xr-x for directories and
>                                 rwxr--r-- for files. If someone thinks
>                                 that's wrong in general; speak up. ;).
>                                 Otherwise I think any deviation from
>                                 that we should justify. Not that
>                                 deviations are wrong, just that they
>                                 need to have a reason.
>
>                                 On Wed, Nov 29, 2017 at 3:12 AM,
>                                 Romain Pelisse <belaran at redhat.com
>                                 <mailto:belaran at redhat.com>> wrote:
>
>                                     Well, the diff is between the RPM
>                                     and the zipfile is pretty long,
>                                     but it boils down to the 3 set of
>                                     differences I've pointed out on
>                                     WFLY-9574:
>                                     <https://issues.jboss.org/browse/WFLY-9574>
>
>                                       * *.properties and .jar* files
>                                         are associated with the mask
>                                         rw-rw-r-- giving access to it
>                                         to any other users and
>                                         allowing group member to
>                                         modify the file - the RPM
>                                         distribution fixes that by
>                                         removing the write privileges
>                                         for the group (rw-r--r--). I
>                                         personnaly don't see the value
>                                         of letting the group members
>                                         modify those files, I just can
>                                         see how this could be
>                                         exploited, so I would say it
>                                         falls into "clearly wrong and
>                                         not our intent". A case might
>                                         be made for the .properties
>                                         files, but for jars file I
>                                         really don't see a valid use
>                                         case (unless of course, any of
>                                         you know one) ;
>
>                                 There are a few different things here,
>                                 so let's deal with them separately.
>
>                                 For jars, with an unzip of
>                                 wildfly-11.0.0.Final.zip, I see them
>                                 as rwxr--r--. Which seems correct to
>                                 me. In case I'm seeing something
>                                 wrong, I don't see why they should
>                                 vary from the general standard. And
>                                 the module.xml file should be
>                                 consistent, since there's not much
>                                 point in locking people from touching
>                                 jars but letting them change what jars
>                                 get loaded.
>
>                                 For properties files, let's consider
>                                 them on a more fine-grained basis. For
>                                 example, the properties files used by
>                                 the security realms have different
>                                 kinds of data than logging.properties
>                                 does.
>
>                                 The perms on the security realm
>                                 property files are rw-------, not
>                                 rw-rw-r--.
>
>                                 The logging.properties files are
>                                 rw-r--r-- which is consistent with the
>                                 domain|host|standalone.xml files and
>                                 with the general standard.
>
>                                      *
>
>
>                                       * *some directories* like
>                                         'domain/tmp/auth' have too
>                                         restrictive mask like
>                                         rwx------ and RPMS to turned
>                                         them into rwxrwxr-x (that I
>                                         don't really agree with) and
>
>                                       * *other directories*, likes
>                                         'domain' have again a too
>                                         permissive mask rwxrwxr-x
>                                         (should be rwxr-xr-x) - and
>                                         this IMHO, make senses.
>
>                                 In the unzip I see these directories
>                                 as rwxr-xr-x, which I think is fine.
>
>                                 Are you concerned with any other
>                                 directories besides $JBOSS_HOME/domain
>                                 and $JBOSS_HOME/standalone?
>
>                                     So we need to find an agreement on
>                                     those three items, and then see
>                                     how we proceed to implement the
>                                     fix (if needed).
>
>
>                                     On Tue, Nov 28, 2017 at 10:00 PM,
>                                     Brian Stansberry
>                                     <brian.stansberry at redhat.com
>                                     <mailto:brian.stansberry at redhat.com>>
>                                     wrote:
>
>                                         I think we need to start with
>                                         the assumption that the
>                                         permissions we have in the zip
>                                         are the way they are for a
>                                         reason and evaluate possible
>                                         changes based on discussion
>                                         here of each type of change.
>                                         Maybe the RPM settings are
>                                         better, maybe they are not. Or
>                                         maybe they are better but the
>                                         improvement is not worth the
>                                         disruption a change may cause
>                                         to our end users, who may rely
>                                         on the current zip settings.
>                                         Or maybe what we have in the
>                                         zip is clearly wrong and
>                                         doesn't follow our own intent.
>                                         I expect we'll probably see a
>                                         little of each category,
>                                         although hopefully some
>                                         changes for WF 11 removed the
>                                         "clearly wrong and doesn't
>                                         follow our intent" cases. :)
>
>                                         On Tue, Nov 28, 2017 at 8:37
>                                         AM, Romain Pelisse
>                                         <belaran at redhat.com
>                                         <mailto:belaran at redhat.com>>
>                                         wrote:
>
>                                             Hi,
>
>                                             As reported on
>                                             JBEAP-12374[1], there is
>                                             some discrepancies between
>                                             the ZIP file we provided
>                                             for Widlfy/EAP and the RPM
>                                             generate. Most of those
>                                             discrepancies - or the
>                                             most relevant ones, are
>                                             some fine tuning performed
>                                             on the (POSIX) privileges
>                                             (things such as removing
>                                             the write privilege for
>                                             member of the same group
>                                             as the owner of the file).
>
>                                             I've looked into this and
>                                             because those files are
>                                             produced by our own Maven
>                                             plugin (as part of
>                                             wildfly-build-tools), we
>                                             can not simply modify the
>                                             assembly.xml. Which
>                                             actually is probably for
>                                             the best, as it would made
>                                             the assembly file quite
>                                             cumbersome.
>
>                                             Anyhow, I've worked on a
>                                             proposal[2] for the
>                                             wildfly-build-tools, but
>                                             when I reported the
>                                             problem on WFLY-9574[3],
>                                             Brian suggested I started
>                                             a discussion here. So does
>                                             anyone have a (strong)
>                                             opinion about this issue
>                                             and/or how to resolve it ? :)
>
>                                             (For the record, I do
>                                             think it is best to fix
>                                             the privileges to follow
>                                             what the RPM does for us
>                                             for now, but if you feel
>                                             this issue should not be
>                                             addressed, and dev- the
>                                             issue, I'm certainly not
>                                             opposed to it either).
>
>                                             [1]
>                                             https://issues.jboss.org/browse/JBEAP-12374
>                                             <https://issues.jboss.org/browse/JBEAP-12374>
>                                             [2]
>                                             https://github.com/wildfly/wildfly-build-tools/pull/40
>                                             <https://github.com/wildfly/wildfly-build-tools/pull/40>
>                                             [3]
>                                             https://issues.jboss.org/browse/WFLY-9574
>                                             <https://issues.jboss.org/browse/WFLY-9574>
>
>                                             _______________________________________________
>                                             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
>                                             <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>
>
>                                         -- 
>                                         Brian Stansberry
>                                         Manager, Senior Principal
>                                         Software Engineer
>                                         Red Hat
>
>
>
>
>
>                                 -- 
>                                 Brian Stansberry
>                                 Manager, Senior Principal Software
>                                 Engineer
>                                 Red Hat
>
>
>
>
>                             -- 
>                             Brian Stansberry
>                             Manager, Senior Principal Software Engineer
>                             Red Hat
>
>
>
>
>
>                     -- 
>                     Brian Stansberry
>                     Manager, Senior Principal Software Engineer
>                     Red Hat
>
>
>
>
>                 -- 
>                 Brian Stansberry
>                 Manager, Senior Principal Software Engineer
>                 Red Hat
>
>
>
>
>
>         -- 
>         Brian Stansberry
>         Manager, Senior Principal Software Engineer
>         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
>     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>
>
> -- 
> 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/20171212/dcaaeb2d/attachment-0001.html 

From darran.lofthouse at jboss.com  Tue Dec 12 05:48:24 2017
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Tue, 12 Dec 2017 10:48:24 +0000
Subject: [wildfly-dev] GRPC subsystem proof of concept
In-Reply-To: <CAAoo=c5XKAs5=u5shjA=p-puAqu0+HtS14U+f_KjqVVqH1_urg@mail.gmail.com>
References: <CAAoo=c5XKAs5=u5shjA=p-puAqu0+HtS14U+f_KjqVVqH1_urg@mail.gmail.com>
Message-ID: <CAMxVf4PWkB1JJ97mHRYvrYeT8nFj0EaAYa612BJVNSnzAkVdww@mail.gmail.com>

On the security question, if we are interested in pursuing this we will get
an analysis document started to look at the options we have for integration
with our security implementation.

Regards,
Darran Lofthouse.



On Mon, 11 Dec 2017 at 05:17 Stuart Douglas <stuart.w.douglas at gmail.com>
wrote:

> Hi everyone,
>
> I have done up a proof of concept of GRPC support in Wildfly, which can be
> found at [1]. GRPC is an RPC protocol designed by Google, that allows for
> easy cross platform invocations.
>
> My proof of concept uses an Undertow based port of GRPC [2] and basically
> works as follows:
>
> - At deployment time Jandex is used to find all non-abstract classes that
> implement io.grpc.BindableService
> - I scan the class hierarchy of these classes to find the protobuf
> generated base class, and create a subclass of this class using
> ProxyFactory, overriding every method except bindService().
> - An instance/proxy is created using the ComponentRegistry to do the
> creation, and the generated proxy delegates all incoming calls to this
> instance
> - At runtime any incoming HTTP/2 requests with a type of application/grpc
> are intercepted, and passed through this newly created proxy.
>
> Basically this means that all you need to do as an application developer
> is define your GRPC endpoints using protobuf, implement the classes
> generated by the protobuf compiler and then include them in your
> application, and Wildfly will do the rest. CDI and EJB annotations on your
> GRPC services should work as normal, for example if you put @Stateless on
> an endpoint it should work as expected with a SFSB handling all invocations.
>
> Note that this is a very early stage POC, and lots of stuff is missing
> (most notably security).
>
> Before I go to much further though I though that I should get some
> feedback, e.g.
>
> - Do we actually want this? I am not sure how much interest there is, but
> it seems like GRPC could be very useful in a polyglot microservice
> environment.
> - Is the current implementation the best way of actually registering GRPC
> services, or should we require some kind of defining annotation
> - What security mechanisms should we support? Out of the box standard GRPC
> is fairly limited
> - What do we do about transactions? I am leaning towards not supporting
> them over GRPC, as we already have solutions for Java invocation in the
> form of our EJB protocol, and I think non-Java clients are unlikely to want
> to use this.
>
> Stuart
>
> [1] https://github.com/stuartwdouglas/wildfly/tree/grpc
> [2] https://github.com/stuartwdouglas/undertow-grpc
> _______________________________________________
> 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/20171212/97650bdc/attachment.html 

From anmiller at redhat.com  Tue Dec 12 09:30:11 2017
From: anmiller at redhat.com (Andrig Miller)
Date: Tue, 12 Dec 2017 07:30:11 -0700
Subject: [wildfly-dev] GRPC subsystem proof of concept
In-Reply-To: <CAMxVf4PWkB1JJ97mHRYvrYeT8nFj0EaAYa612BJVNSnzAkVdww@mail.gmail.com>
References: <CAAoo=c5XKAs5=u5shjA=p-puAqu0+HtS14U+f_KjqVVqH1_urg@mail.gmail.com>
	<CAMxVf4PWkB1JJ97mHRYvrYeT8nFj0EaAYa612BJVNSnzAkVdww@mail.gmail.com>
Message-ID: <CAF1-sp4372jseCi0vDyV4gVTcvCiqjbDvQ1usUy2EP484qa=GA@mail.gmail.com>

Stuart,

      Because I have memory footprint on the brain, pretty much all the
time now, I wonder if you can change your approach in a way that would
lessen MetaSpace usage.  MetaSpace usage is usually the second largest
memory hog in Wildfly/EAP, and under certain circumstances it can be larger
than heap, when the right JVM settings are used to control heap usage (part
of my presentation in 30 minutes).

Andy

On Tue, Dec 12, 2017 at 3:48 AM, Darran Lofthouse <
darran.lofthouse at jboss.com> wrote:

> On the security question, if we are interested in pursuing this we will
> get an analysis document started to look at the options we have for
> integration with our security implementation.
>
> Regards,
> Darran Lofthouse.
>
>
>
> On Mon, 11 Dec 2017 at 05:17 Stuart Douglas <stuart.w.douglas at gmail.com>
> wrote:
>
>> Hi everyone,
>>
>> I have done up a proof of concept of GRPC support in Wildfly, which can
>> be found at [1]. GRPC is an RPC protocol designed by Google, that allows
>> for easy cross platform invocations.
>>
>> My proof of concept uses an Undertow based port of GRPC [2] and basically
>> works as follows:
>>
>> - At deployment time Jandex is used to find all non-abstract classes that
>> implement io.grpc.BindableService
>> - I scan the class hierarchy of these classes to find the protobuf
>> generated base class, and create a subclass of this class using
>> ProxyFactory, overriding every method except bindService().
>> - An instance/proxy is created using the ComponentRegistry to do the
>> creation, and the generated proxy delegates all incoming calls to this
>> instance
>> - At runtime any incoming HTTP/2 requests with a type of application/grpc
>> are intercepted, and passed through this newly created proxy.
>>
>> Basically this means that all you need to do as an application developer
>> is define your GRPC endpoints using protobuf, implement the classes
>> generated by the protobuf compiler and then include them in your
>> application, and Wildfly will do the rest. CDI and EJB annotations on your
>> GRPC services should work as normal, for example if you put @Stateless on
>> an endpoint it should work as expected with a SFSB handling all invocations.
>>
>> Note that this is a very early stage POC, and lots of stuff is missing
>> (most notably security).
>>
>> Before I go to much further though I though that I should get some
>> feedback, e.g.
>>
>> - Do we actually want this? I am not sure how much interest there is, but
>> it seems like GRPC could be very useful in a polyglot microservice
>> environment.
>> - Is the current implementation the best way of actually registering GRPC
>> services, or should we require some kind of defining annotation
>> - What security mechanisms should we support? Out of the box standard
>> GRPC is fairly limited
>> - What do we do about transactions? I am leaning towards not supporting
>> them over GRPC, as we already have solutions for Java invocation in the
>> form of our EJB protocol, and I think non-Java clients are unlikely to want
>> to use this.
>>
>> Stuart
>>
>> [1] https://github.com/stuartwdouglas/wildfly/tree/grpc
>> [2] https://github.com/stuartwdouglas/undertow-grpc
>> _______________________________________________
>> 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
>



-- 
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171212/aa290304/attachment.html 

From brian.stansberry at redhat.com  Tue Dec 12 11:41:52 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 12 Dec 2017 10:41:52 -0600
Subject: [wildfly-dev] WildFly-Camel 5.0.0 released
In-Reply-To: <992D6880-D089-4EB2-9016-C0B11650319E@redhat.com>
References: <992D6880-D089-4EB2-9016-C0B11650319E@redhat.com>
Message-ID: <CAPhbRDbQBjZp0G_3sQvs9bL2wPkY_+4VFFbo89JF-mm71vF3KA@mail.gmail.com>

This is great to see. Thanks, Thomas!

On Fri, Dec 8, 2017 at 6:46 AM, Thomas Diesler <tdiesler at redhat.com> wrote:

> Folks,
>
> I happy to announce that WildFly-Camel 5.0.0
> <https://github.com/wildfly-extras/wildfly-camel/releases/tag/5.0.0> has
> been released.
> It provides Camel-2.20.1 integration with WildFly-11.0.0
>
> This is a major upgrade release for supported components, dataformats and
> languages, which now reaches feature parity with other runtimes.
> i.e. all available dataformats and languages are now also supported on
> WildFly.
>
> Additional components in the supported set
> <http://wildfly-extras.github.io/wildfly-camel/#_camel_components> are:
>
> ? apns
> ? asterisk
> ? atomix
> ? azure-blob
> ? azure-queue
> ? beanstalk
> ? caffeine
> ? chronicle-engine
> ? chunk
> ? cm-sms
> ? consul
> ? couchbase
> ? crypto-cms
> ? digitalocean
> ? docker
> ? elasticsearch5
> ? etcd
> ? flink
> ? google-bigquery
> ? google-calendar
> ? google-drive
> ? google-mail
> ? grpc
> ? guava-eventbus
> ? hazelcast
> ? headersmap
> ? hipchat
> ? iec60870
> ? jclouds
> ? jcr
> ? json-validator
> ? jt400
> ? ldif
> ? leveldb
> ? lumberjack
> ? master
> ? milo
> ? mongodb-gridfs
> ? nagios
> ? olingo4
> ? openstack-cinder
> ? openstack-glance
> ? openstack-keystone
> ? openstack-neutron
> ? openstack-nova
> ? openstack-swift
> ? printer
> ? pubnub
> ? quickfix
> ? reactor
> ? rmi
> ? shiro
> ? sip
> ? sips
> ? slack
> ? spring-javaconfig
> ? spring-ws
> ? stomp
> ? telegram
> ? thrift
> ? twilio
> ? xmpp
> ? yammer
> ? zookeeper-master
>
> Additional data formats in the supported set
> <http://wildfly-extras.github.io/wildfly-camel/#_data_formats> are:
>
> ? asn1
> ? fastjson
> ? thrift
>
> Component upgrades include
>
> ? WildFly-11.0.0
> ? Camel-2.20.1
> ? Hawtio-1.5.5
>
> In addition to that, we also resolved a number of other tasks and bugs
> <https://github.com/wildfly-extras/wildfly-camel/blob/master/docs/Changelog.md>
> .
>
> For details please see the 5.0.0 Milestone
> <https://github.com/wildfly-extras/wildfly-camel/issues?q=milestone:5.0.0>
> .
>
> Enjoy
> ? thomas
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171212/4db43647/attachment-0001.html 

From jperkins at redhat.com  Tue Dec 12 11:47:25 2017
From: jperkins at redhat.com (James Perkins)
Date: Tue, 12 Dec 2017 08:47:25 -0800
Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have
 POSIX permissions perfectly set
In-Reply-To: <0ec575db-fa44-dd31-73a6-766ec0edc7a8@redhat.com>
References: <CALuBA_p5Mqag2+TSD9bUWGM5BgDpirdZC7zvL5OE8w-HfA4AWw@mail.gmail.com>
	<CAPhbRDYyGwNpqFq8bYdRk53_hx6Mg4yHwOcmmYYnwDp_3-B+_A@mail.gmail.com>
	<CALuBA_pSvfNYPug1byQrS7Bic45vVvvdQ4Mjd-BQ6Pa4t5m05g@mail.gmail.com>
	<CAPhbRDYnYLd-SXuE_m_2b14W9VwNhy08KDpC0MdP6n3mipMi0A@mail.gmail.com>
	<CAPhbRDZFTd52gO8-psaaXJSVNAPn=3MtjA3XuyEC501Hj-rRJw@mail.gmail.com>
	<CALuBA_pXT89PNspojT-sT3GNTVhf1R1F7YJPxn7K-B6dmP4+bg@mail.gmail.com>
	<CAPhbRDZFfcuS5kZNHU99cVDSTjewsVynuaZAAxsxdQSswxOZOA@mail.gmail.com>
	<CAPhbRDYN_PGP8fo6BizQ3EOR-=9UT_jrJEECzLBfT-DoOt05fg@mail.gmail.com>
	<CALuBA_qxu=nGP93yfPXEdhiUdxBkQ2C7YZx=82i7qbOA=egr+A@mail.gmail.com>
	<CAPhbRDZAnSLP6OYkWUHkvczj-sm4FGaE6apEEoiGRo_D+Z=nww@mail.gmail.com>
	<CALuBA_pfzAOsZf_fU=sN6uGkCdm04iwAwxJyV4r4gEkupSp2HQ@mail.gmail.com>
	<CADGwLphZ9wWbLh87qrDihpeFzKumGFnkabcq1FzwkWSTRrE6vA@mail.gmail.com>
	<0ec575db-fa44-dd31-73a6-766ec0edc7a8@redhat.com>
Message-ID: <CADGwLpiC9+9ESBFwMGrCD_OYPHr_7+U5+Qmi6Ne6cVkNViv7EQ@mail.gmail.com>

That means the packaging tool has to know about all the files it consumes.
That would make the feature pack concept irrelevant. There could be a
reason the feature pack set specific permissions on a file and the
provisioning tool should honor that. It shouldn't be making assumptions.
Especially if that assumption is determined by a file extension.

On Tue, Dec 12, 2017 at 12:20 AM, Carlo de Wolf <cdewolf at redhat.com> wrote:

> If any target platform needs more restrictive permissions, those need to
> apply to all deliverables (whether it is ZIP or RPMs).
>
> Carlo
>
>
> On 11-12-17 23:28, James Perkins wrote:
>
> I personally don't have any strong opinions on what the permissions should
> be. However as I said before it should definitely not be the provisioning
> plugin that sets these permissions. If they need to be different we need to
> change them in the feature pack.
>
> On Mon, Dec 11, 2017 at 4:47 AM, Romain Pelisse <belaran at redhat.com>
> wrote:
>
>> Hi all,
>>
>> Not too much involvement except from Brian and I :) - sadly, we cannot
>> move forward on this topic without a minimum of consensus. If you don't to
>> participate, can you at least reply "+1 Brian" (if you think we should NOT
>> try to change the current behavior") or "+1 Romain" (if you think we should
>> address this issue somehow).
>>
>> (please don't vote on the PR I've proposed, it's just a proposal on HOW
>> we could do it - here I want to assert IF we want to do it, not voting on
>> the "how").
>>
>> On Wed, Dec 6, 2017 at 6:05 PM, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>>
>>> On Wed, Dec 6, 2017 at 4:27 AM, Romain Pelisse <belaran at redhat.com>
>>> wrote:
>>>
>>>> Hi Brian (and all),
>>>>
>>>> I honestly understand your resistance, and I'm completely fine if we
>>>> end up closing this all issue as WONTDO or REJECTED. I just do want to have
>>>> a discussion about it and come back with clear reasons and motivations for
>>>> changing or not the privileges of each of those files.
>>>>
>>>
>>> Thanks for doing this! There have been a number of issues filed over the
>>> last year or so on this general topic so I'm very happy to see them getting
>>> addressed here via the WildFly community. Most of the issues I've been
>>> talking about are JBEAP issues in JIRA, which is fine, but the best way to
>>> get this solid is to get WildFly the way we want it first.
>>>
>>> Even on the config file read perms thing I mentioned in my last post,
>>> I'm personally resistant to changing it, but my biggest resistance is to
>>> doing that without a full community discussion.
>>>
>>>
>>>> Given that we see different things on our local setup, I think the best
>>>> will be to use a build on a CI Server and works from what we see there. Is
>>>> there an easy way for me to clone a job building Wildfly and tweak it on
>>>> some (publicly) accessible instance ?
>>>>
>>>
>>> https://developer.jboss.org/thread/224262 describes how to get a zip
>>> built from a daily CI job.
>>>
>>> If anyone has any insights on this, please speak up!
>>>
>>>
>>>>
>>>>
>>>> On Mon, Dec 4, 2017 at 6:48 PM, Brian Stansberry <
>>>> brian.stansberry at redhat.com> wrote:
>>>>
>>>>> A slightly different topic, related to the "logging.properties/xml
>>>>> config file" topic is whether these files should be world and/or group
>>>>> readable.
>>>>>
>>>>> Changing this has been proposed in the past on the EAP side, primarily
>>>>> based on the argument that users could put sensitive data in these files.
>>>>> This thread seems like a good time to debate this a bit in community.
>>>>>
>>>>> I've resisted that primarily on the basis of:
>>>>>
>>>>> 1) These files or those similarly used have had these perms as far
>>>>> back as I can find in JBoss AS. So the odds that some people are relying
>>>>> upon those perms is fairly high and we need to assume a change would be a
>>>>> breaking change for some people.
>>>>>
>>>>> 2) Other software I've looked at like Tomcat and httpd have similar
>>>>> permission schemes to what we have for their config files, which can also
>>>>> potentially include sensitive data.
>>>>>
>>>>> 3) We provide facilities like the vault or elytron credential store
>>>>> refs for keeping sensitive data out of the config files.
>>>>>
>>>>>
>>>>> On Mon, Dec 4, 2017 at 11:38 AM, Brian Stansberry <
>>>>> brian.stansberry at redhat.com> wrote:
>>>>>
>>>>>> Thanks, Romain.
>>>>>>
>>>>>> Re: what the actual permissions are, FWIW I get what I see on both my
>>>>>> macbook and my Fedora 27 machine, both when unzipping the actual
>>>>>> 11.0.0.Final and when unzipping the result of a build of master, and both
>>>>>> with and without the -Prelease -Pjboss-release args to maven that we
>>>>>> include when doing actual releases. Unzipping the zip in build/target
>>>>>> doesn't include the jars of course.
>>>>>>
>>>>>> So it sounds like we need input from others.
>>>>>>
>>>>>> Re: modules.xml, if you are seeing those as rw-r--r-- as well, then
>>>>>> +1 to ignoring them in further discussion.
>>>>>>
>>>>>> Re: logging.properties, those serve a very similar conceptual role to
>>>>>> the standalone|host|domain.xml files so I see no reason for them to have
>>>>>> different perms. However, you and I are getting different results, where
>>>>>> you report them as group writable and I don't. What do you see for the xml
>>>>>> config files?
>>>>>>
>>>>>> Re: RPM changing to match WildFly, that's an EAP discussion, so that
>>>>>> can be taken up elsewhere once we have WildFly the way we want it.
>>>>>>
>>>>>>
>>>>>> On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse <belaran at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Brian and all,
>>>>>>>
>>>>>>> err, my own observation differs from yours. I've rebuild Wildfly
>>>>>>> from the last content of the master branch and get the same privileges on
>>>>>>> the jboss-modules.jar (so -rw-rw-r-- and not as you are seeing  rwxr--r--).
>>>>>>> Same with the domain folder, which turns out on my local system associated
>>>>>>> to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a
>>>>>>> transcript of what I did - maybe you can spot why our results differs so
>>>>>>> much.
>>>>>>>
>>>>>>> $ git show
>>>>>>> commit 46e119c65d9e32bc0ec69f3933267fece959ed3f
>>>>>>> Merge: 051f080 c7d9075
>>>>>>> Author: Kabir Khan <kkhan at redhat.com>
>>>>>>> Date:   Tue Nov 28 17:46:40 2017 +0000
>>>>>>>
>>>>>>>     Merge pull request #10669 from praxeo/WFLY-9284
>>>>>>>
>>>>>>>     WFLY-9284 Correct MVN env variable to mvnw.cmd
>>>>>>>
>>>>>>> $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d
>>>>>>> wildfly-12.zip
>>>>>>> ...
>>>>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.
>>>>>>> jar
>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov.  11:41
>>>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
>>>>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/  -d
>>>>>>> drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov.  11:41
>>>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/
>>>>>>>
>>>>>>> Checking all the jars in the distribution, they all appears to have
>>>>>>> the mask '-rw-rw-r--':
>>>>>>>
>>>>>>> $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done |
>>>>>>> sed -e '/-rw-rw-r--/d'
>>>>>>> $
>>>>>>>
>>>>>>> Regarding properties files, here is the exhaustive list of
>>>>>>> properties that RPM packaging has modified the privileges of:
>>>>>>>
>>>>>>> appclient/configuration/logging.properties rw-------
>>>>>>> domain/configuration/application-roles.properties rw-------
>>>>>>> domain/configuration/default-server-logging.properties rw-------
>>>>>>> domain/configuration/logging.properties rw-------
>>>>>>> domain/configuration/mgmt-groups.properties rw-------
>>>>>>> standalone/configuration/application-roles.properties rw-------
>>>>>>> standalone/configuration/logging.properties rw-------
>>>>>>> standalone/configuration/mgmt-groups.properties rw-------
>>>>>>>
>>>>>>> If I compare that with the content of the extract zip (same fresh
>>>>>>> built as above), I can see that 4 files are not having the same mask
>>>>>>> (rw------):
>>>>>>>
>>>>>>> $ for file in $(cut -f1 -d\  ../../../list-props-files.txt ); do ls
>>>>>>> -l $file ; done
>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>>>>>> appclient/configuration/logging.properties
>>>>>>> -rw-------. 1 rpelisse rpelisse 710 30 nov.  11:41
>>>>>>> domain/configuration/application-roles.properties
>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>>>>>> domain/configuration/default-server-logging.properties
>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>>>>>> domain/configuration/logging.properties
>>>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>>>>>> domain/configuration/mgmt-groups.properties
>>>>>>> -rw-------. 1 rpelisse rpelisse 711 30 nov.  11:41
>>>>>>> standalone/configuration/application-roles.properties
>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>>>>>> standalone/configuration/logging.properties
>>>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>>>>>> standalone/configuration/mgmt-groups.properties
>>>>>>>
>>>>>>> Now, as you said, those files privileges are indeed fine-grained, so
>>>>>>> maybe we can push back to people making the RPM for them to NOT change the
>>>>>>> following files privileges:
>>>>>>>
>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>>>>>> appclient/configuration/logging.properties
>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>>>>>> domain/configuration/default-server-logging.properties
>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>>>>>> domain/configuration/logging.properties
>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>>>>>> standalone/configuration/logging.properties
>>>>>>>
>>>>>>> However, I don't see the value of letting those files accessible
>>>>>>> either group member or any user on the system, but maybe we can make the
>>>>>>> argument they should. But the write privileges for group member sounds
>>>>>>> wrong to me.
>>>>>>>
>>>>>>> Also, I'm puzzled Brian and I are seeing different things - am I
>>>>>>> looking at the correct zipfile here ?
>>>>>>>
>>>>>>> Note: You also mention the module.xml - as far as I can see from the
>>>>>>> diff provided with issue JBEAP-12374, I don't see any issue with privileges
>>>>>>> regarding those files, so we can remove them of the discussion. The only
>>>>>>> changes we need to discuss is removing the 'write' privileges' for the
>>>>>>> group on jars, reducing the scope of permissions on (some) folders, and
>>>>>>> privileges on (some) properties files. So, module.xml are out of the scope.
>>>>>>>
>>>>>>> On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry <
>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>
>>>>>>>> Seems I forgot to "Reply to All" yesterday. The following was meant
>>>>>>>> to be sent to wildfly-dev.
>>>>>>>>
>>>>>>>> On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry <
>>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> Before getting into the specifics, first a general note re: perms.
>>>>>>>>>
>>>>>>>>> Our general permission set for is rwxr-xr-x for directories and
>>>>>>>>> rwxr--r-- for files. If someone thinks that's wrong in general; speak up.
>>>>>>>>> ;). Otherwise I think any deviation from that we should justify. Not that
>>>>>>>>> deviations are wrong, just that they need to have a reason.
>>>>>>>>>
>>>>>>>>> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <
>>>>>>>>> belaran at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> Well, the diff is between the RPM and the zipfile is pretty long,
>>>>>>>>>> but it boils down to the 3 set of differences I've pointed out on
>>>>>>>>>> WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574>
>>>>>>>>>>
>>>>>>>>>>    - *.properties and .jar* files are associated with the mask
>>>>>>>>>>    rw-rw-r-- giving access to it to any other users and allowing group member
>>>>>>>>>>    to modify the file - the RPM distribution fixes that by removing the write
>>>>>>>>>>    privileges for the group (rw-r--r--). I personnaly don't see the value of
>>>>>>>>>>    letting the group members modify those files, I just can see how this could
>>>>>>>>>>    be exploited, so I would say it falls into "clearly wrong and not our
>>>>>>>>>>    intent". A case might be made for the .properties files, but for jars file
>>>>>>>>>>    I really don't see a valid use case (unless of course, any of you know one)
>>>>>>>>>>    ;
>>>>>>>>>>
>>>>>>>>>> There are a few different things here, so let's deal with them
>>>>>>>>> separately.
>>>>>>>>>
>>>>>>>>> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as
>>>>>>>>> rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I
>>>>>>>>> don't see why they should vary from the general standard. And the
>>>>>>>>> module.xml file should be consistent, since there's not much point in
>>>>>>>>> locking people from touching jars but letting them change what jars get
>>>>>>>>> loaded.
>>>>>>>>>
>>>>>>>>> For properties files, let's consider them on a more fine-grained
>>>>>>>>> basis. For example, the properties files used by the security realms have
>>>>>>>>> different kinds of data than logging.properties does.
>>>>>>>>>
>>>>>>>>> The perms on the security realm property files are rw-------, not
>>>>>>>>> rw-rw-r--.
>>>>>>>>>
>>>>>>>>> The logging.properties files are rw-r--r-- which is consistent
>>>>>>>>> with the domain|host|standalone.xml files and with the general standard.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    -
>>>>>>>>>>    - *some directories* like 'domain/tmp/auth' have too
>>>>>>>>>>    restrictive mask like rwx------ and RPMS to turned them into rwxrwxr-x
>>>>>>>>>>    (that I don't really agree with) and
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>    - *other directories*, likes 'domain' have again a too
>>>>>>>>>>    permissive mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make
>>>>>>>>>>    senses.
>>>>>>>>>>
>>>>>>>>>> In the unzip I see these directories as rwxr-xr-x, which I think
>>>>>>>>> is fine.
>>>>>>>>>
>>>>>>>>> Are you concerned with any other directories besides
>>>>>>>>> $JBOSS_HOME/domain and $JBOSS_HOME/standalone?
>>>>>>>>>
>>>>>>>>>> So we need to find an agreement on those three items, and then
>>>>>>>>>> see how we proceed to implement the fix (if needed).
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry <
>>>>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I think we need to start with the assumption that the
>>>>>>>>>>> permissions we have in the zip are the way they are for a reason and
>>>>>>>>>>> evaluate possible changes based on discussion here of each type of change.
>>>>>>>>>>> Maybe the RPM settings are better, maybe they are not. Or maybe they are
>>>>>>>>>>> better but the improvement is not worth the disruption a change may cause
>>>>>>>>>>> to our end users, who may rely on the current zip settings. Or maybe what
>>>>>>>>>>> we have in the zip is clearly wrong and doesn't follow our own intent. I
>>>>>>>>>>> expect we'll probably see a little of each category, although hopefully
>>>>>>>>>>> some changes for WF 11 removed the "clearly wrong and doesn't follow our
>>>>>>>>>>> intent" cases. :)
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <
>>>>>>>>>>> belaran at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> As reported on JBEAP-12374[1], there is some discrepancies
>>>>>>>>>>>> between the ZIP file we provided for Widlfy/EAP and the RPM generate. Most
>>>>>>>>>>>> of those discrepancies - or the most relevant ones, are some fine tuning
>>>>>>>>>>>> performed on the (POSIX) privileges (things such as removing the write
>>>>>>>>>>>> privilege for member of the same group as the owner of the file).
>>>>>>>>>>>>
>>>>>>>>>>>> I've looked into this and because those files are produced by
>>>>>>>>>>>> our own Maven plugin (as part of wildfly-build-tools), we can not simply
>>>>>>>>>>>> modify the assembly.xml. Which actually is probably for the best, as it
>>>>>>>>>>>> would made the assembly file quite cumbersome.
>>>>>>>>>>>>
>>>>>>>>>>>> Anyhow, I've worked on a proposal[2] for the
>>>>>>>>>>>> wildfly-build-tools, but when I reported the problem on WFLY-9574[3], Brian
>>>>>>>>>>>> suggested I started a discussion here. So does anyone have a (strong)
>>>>>>>>>>>> opinion about this issue and/or how to resolve it ? :)
>>>>>>>>>>>>
>>>>>>>>>>>> (For the record, I do think it is best to fix the privileges to
>>>>>>>>>>>> follow what the RPM does for us for now, but if you feel this issue should
>>>>>>>>>>>> not be addressed, and dev- the issue, I'm certainly not opposed to it
>>>>>>>>>>>> either).
>>>>>>>>>>>>
>>>>>>>>>>>> [1] https://issues.jboss.org/browse/JBEAP-12374
>>>>>>>>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40
>>>>>>>>>>>> [3] https://issues.jboss.org/browse/WFLY-9574
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Brian Stansberry
>>>>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>>>>> Red Hat
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Brian Stansberry
>>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>>> Red Hat
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Brian Stansberry
>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>> Red Hat
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Brian Stansberry
>>>>>> Manager, Senior Principal Software Engineer
>>>>>> Red Hat
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Manager, Senior Principal Software Engineer
>>>>> Red Hat
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> Red Hat
>>>
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://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/20171212/d151a715/attachment-0001.html 

From brian.stansberry at redhat.com  Tue Dec 12 12:15:27 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 12 Dec 2017 11:15:27 -0600
Subject: [wildfly-dev] Run level as a factor for capabilities and
	requirements?
Message-ID: <CAPhbRDbKDJbH+LgL7emM4we0m2sW-0CEigxjZvzeAmX0OzF_hg@mail.gmail.com>

Something the current capabilities/requirements stuff doesn't handle is the
fact that some capabilities can be configured but won't be turned on in
some situations (i.e. admin-only). Which means other capabilities that
might require them and that are present in admin-only will pass
configuration consistency checks but will fail at runtime.

I'm not sure what to do about this. Some off the top of my head thoughts:

1) The capability description data on wildly-capabilities includes
something about this, so people who want to require the capability
understand whether it can be required.

This is easy, and helps avoids future bugs. It's just documentation so it
does nothing about the actual server behavior.

2) The registration for capabilities could include "minimal running-mode"
data, and then the capability resolution could check that and fail if it
finds a mismatch in the current running mode.

This is more work obviously. It may help surface problems earlier, i.e.
make it more likely that a testsuite catches a mismatch in time to correct
it before a .Final release. It would also have the minor benefit of perhaps
providing a better error message for a user who configures a mismatch.

3) The management layer could somehow makes this data available to
subsystems so they could utilize it. So, the requiror sees the required cap
is not available in the current run level so it in turn doesn't try and
install its own cap. Instead logs a WARN or something.

This is the most work, and I have huge doubts about its wisdom. The
software no longer is reasonably predictable, where something is on or off
in a given run level; now it's or off depending on whether something else
is on or off.

For any of these we'll need to formalize our existing concepts into a solid
run-level concept. I don't think that should be too hard.

[1] https://github.com/wildfly/wildfly-capabilities

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171212/b7986efb/attachment.html 

From brian.stansberry at redhat.com  Tue Dec 12 12:37:28 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 12 Dec 2017 11:37:28 -0600
Subject: [wildfly-dev] Logging Changes
In-Reply-To: <CANghgrRrbV_ksi8FBOSQthc1XLsVrc-sNyBGz69tJFgD00GFiQ@mail.gmail.com>
References: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
	<CANghgrRrbV_ksi8FBOSQthc1XLsVrc-sNyBGz69tJFgD00GFiQ@mail.gmail.com>
Message-ID: <CAPhbRDYr1yV1NVGxiuteM9wHnEZZE8PKzS7yD8mnCg1-EswWaQ@mail.gmail.com>

On Thu, Dec 7, 2017 at 5:46 PM, David Lloyd <david.lloyd at redhat.com> wrote:

> On Thu, Dec 7, 2017 at 2:02 PM, James Perkins <jperkins at redhat.com> wrote:
> > There will be a slight performance impact during boot. This can be
> greatly
> > reduced if the caller calculation is disabled. This can be done in normal
> > cases, but we likely can't make it the default.
>
> I suspect we can safely disable caller calculation by default on boot,
> as long as users have an easy way to turn it on.
>
> Also I think we should consider some kind of grimy hack to bootstrap
> the logging subsystem first, if it's present, otherwise immediately
> fall back to properties-based config if it's absent.
>
> I'm not sure what counts as first in this context, but fwiw if a logging
subsystem is present during boot we always execute it's Stage.RUNTIME steps
first before proceeding on to doing the parallel execution of the other
subsystems. We could probably without too much trouble get a bit more
grimy, e.g. to get the subsystem ops to run before a few others if they
don't already. Beyond that I sense we wouldn't be talking grimy, we'd be
talking horrible. :)

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



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171212/094f0f26/attachment.html 

From jperkins at redhat.com  Tue Dec 12 13:45:13 2017
From: jperkins at redhat.com (James Perkins)
Date: Tue, 12 Dec 2017 10:45:13 -0800
Subject: [wildfly-dev] Logging Changes
In-Reply-To: <CAPhbRDYr1yV1NVGxiuteM9wHnEZZE8PKzS7yD8mnCg1-EswWaQ@mail.gmail.com>
References: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
	<CANghgrRrbV_ksi8FBOSQthc1XLsVrc-sNyBGz69tJFgD00GFiQ@mail.gmail.com>
	<CAPhbRDYr1yV1NVGxiuteM9wHnEZZE8PKzS7yD8mnCg1-EswWaQ@mail.gmail.com>
Message-ID: <CADGwLpgfOhDfW_yE21=EdN5aA75qZNKYoSz=xdHXsYXQP+WqTw@mail.gmail.com>

On Tue, Dec 12, 2017 at 9:37 AM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

>
>
> On Thu, Dec 7, 2017 at 5:46 PM, David Lloyd <david.lloyd at redhat.com>
> wrote:
>
>> On Thu, Dec 7, 2017 at 2:02 PM, James Perkins <jperkins at redhat.com>
>> wrote:
>> > There will be a slight performance impact during boot. This can be
>> greatly
>> > reduced if the caller calculation is disabled. This can be done in
>> normal
>> > cases, but we likely can't make it the default.
>>
>> I suspect we can safely disable caller calculation by default on boot,
>> as long as users have an easy way to turn it on.
>>
>> Also I think we should consider some kind of grimy hack to bootstrap
>> the logging subsystem first, if it's present, otherwise immediately
>> fall back to properties-based config if it's absent.
>>
>> I'm not sure what counts as first in this context, but fwiw if a logging
> subsystem is present during boot we always execute it's Stage.RUNTIME steps
> first before proceeding on to doing the parallel execution of the other
> subsystems. We could probably without too much trouble get a bit more
> grimy, e.g. to get the subsystem ops to run before a few others if they
> don't already. Beyond that I sense we wouldn't be talking grimy, we'd be
> talking horrible. :)
>

Darran and I had a brief discussion about what we could do because at least
parts of Elytron and logging are generally needed before other things are
configured. Elytron would likely need to be first because logging will have
to use capabilities from it.

I've wondered if there should be a new Stage.PRE_RUNTIME type of stage, but
I can also see where that may get abused.


>
> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>



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

From brian.stansberry at redhat.com  Tue Dec 12 14:10:02 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 12 Dec 2017 13:10:02 -0600
Subject: [wildfly-dev] Logging Changes
In-Reply-To: <CADGwLpgfOhDfW_yE21=EdN5aA75qZNKYoSz=xdHXsYXQP+WqTw@mail.gmail.com>
References: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
	<CANghgrRrbV_ksi8FBOSQthc1XLsVrc-sNyBGz69tJFgD00GFiQ@mail.gmail.com>
	<CAPhbRDYr1yV1NVGxiuteM9wHnEZZE8PKzS7yD8mnCg1-EswWaQ@mail.gmail.com>
	<CADGwLpgfOhDfW_yE21=EdN5aA75qZNKYoSz=xdHXsYXQP+WqTw@mail.gmail.com>
Message-ID: <CAPhbRDYG5gVLWPOTODiO0Wd5te57xJA2+zJyF6joNnB__ZcuDg@mail.gmail.com>

On Tue, Dec 12, 2017 at 12:45 PM, James Perkins <jperkins at redhat.com> wrote:

>
>
> On Tue, Dec 12, 2017 at 9:37 AM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>>
>>
>> On Thu, Dec 7, 2017 at 5:46 PM, David Lloyd <david.lloyd at redhat.com>
>> wrote:
>>
>>> On Thu, Dec 7, 2017 at 2:02 PM, James Perkins <jperkins at redhat.com>
>>> wrote:
>>> > There will be a slight performance impact during boot. This can be
>>> greatly
>>> > reduced if the caller calculation is disabled. This can be done in
>>> normal
>>> > cases, but we likely can't make it the default.
>>>
>>> I suspect we can safely disable caller calculation by default on boot,
>>> as long as users have an easy way to turn it on.
>>>
>>> Also I think we should consider some kind of grimy hack to bootstrap
>>> the logging subsystem first, if it's present, otherwise immediately
>>> fall back to properties-based config if it's absent.
>>>
>>> I'm not sure what counts as first in this context, but fwiw if a logging
>> subsystem is present during boot we always execute it's Stage.RUNTIME steps
>> first before proceeding on to doing the parallel execution of the other
>> subsystems. We could probably without too much trouble get a bit more
>> grimy, e.g. to get the subsystem ops to run before a few others if they
>> don't already. Beyond that I sense we wouldn't be talking grimy, we'd be
>> talking horrible. :)
>>
>
> Darran and I had a brief discussion about what we could do because at
> least parts of Elytron and logging are generally needed before other things
> are configured. Elytron would likely need to be first because logging will
> have to use capabilities from it.
>
> I've wondered if there should be a new Stage.PRE_RUNTIME type of stage,
> but I can also see where that may get abused.
>

This is starting to smell bad.

Elytron needs DS it seems, and DS needs ? and, well, this is why we use
MSC. :)  We hadn't had deps from logging to other subsystems before, which
is what made the minor boot op ordering tricks we do useful, but since we
now do, then we're really down to MSC. Boot op ordering tricks can help
optimize common cases like a logging subsystem not having elytron
dependencies, but I don't think we should try and create a duplicate MSC.


>
>
>>
>> --
>>> - DML
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171212/0fdd05b6/attachment-0001.html 

From david.lloyd at redhat.com  Tue Dec 12 14:11:48 2017
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 12 Dec 2017 13:11:48 -0600
Subject: [wildfly-dev] Logging Changes
In-Reply-To: <CAPhbRDYr1yV1NVGxiuteM9wHnEZZE8PKzS7yD8mnCg1-EswWaQ@mail.gmail.com>
References: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
	<CANghgrRrbV_ksi8FBOSQthc1XLsVrc-sNyBGz69tJFgD00GFiQ@mail.gmail.com>
	<CAPhbRDYr1yV1NVGxiuteM9wHnEZZE8PKzS7yD8mnCg1-EswWaQ@mail.gmail.com>
Message-ID: <CANghgrQn=F619nLZfYxoJsZfD=jBjCAvGtS2Cq5YNoDgvaeUwQ@mail.gmail.com>

On Tue, Dec 12, 2017 at 11:37 AM, Brian Stansberry
<brian.stansberry at redhat.com> wrote:
> On Thu, Dec 7, 2017 at 5:46 PM, David Lloyd <david.lloyd at redhat.com> wrote:
>> On Thu, Dec 7, 2017 at 2:02 PM, James Perkins <jperkins at redhat.com> wrote:
>> > There will be a slight performance impact during boot. This can be
>> > greatly
>> > reduced if the caller calculation is disabled. This can be done in
>> > normal
>> > cases, but we likely can't make it the default.
>>
>> I suspect we can safely disable caller calculation by default on boot,
>> as long as users have an easy way to turn it on.
>>
>> Also I think we should consider some kind of grimy hack to bootstrap
>> the logging subsystem first, if it's present, otherwise immediately
>> fall back to properties-based config if it's absent.
>>
> I'm not sure what counts as first in this context, but fwiw if a logging
> subsystem is present during boot we always execute it's Stage.RUNTIME steps
> first before proceeding on to doing the parallel execution of the other
> subsystems.

OK, that's exactly what I was alluding to, and we already do it, so
it's all fine then.

-- 
- DML

From kwills at redhat.com  Tue Dec 12 14:44:47 2017
From: kwills at redhat.com (Ken Wills)
Date: Tue, 12 Dec 2017 19:44:47 +0000
Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have
 POSIX permissions perfectly set
In-Reply-To: <CALuBA_pfzAOsZf_fU=sN6uGkCdm04iwAwxJyV4r4gEkupSp2HQ@mail.gmail.com>
References: <CALuBA_p5Mqag2+TSD9bUWGM5BgDpirdZC7zvL5OE8w-HfA4AWw@mail.gmail.com>
	<CAPhbRDYyGwNpqFq8bYdRk53_hx6Mg4yHwOcmmYYnwDp_3-B+_A@mail.gmail.com>
	<CALuBA_pSvfNYPug1byQrS7Bic45vVvvdQ4Mjd-BQ6Pa4t5m05g@mail.gmail.com>
	<CAPhbRDYnYLd-SXuE_m_2b14W9VwNhy08KDpC0MdP6n3mipMi0A@mail.gmail.com>
	<CAPhbRDZFTd52gO8-psaaXJSVNAPn=3MtjA3XuyEC501Hj-rRJw@mail.gmail.com>
	<CALuBA_pXT89PNspojT-sT3GNTVhf1R1F7YJPxn7K-B6dmP4+bg@mail.gmail.com>
	<CAPhbRDZFfcuS5kZNHU99cVDSTjewsVynuaZAAxsxdQSswxOZOA@mail.gmail.com>
	<CAPhbRDYN_PGP8fo6BizQ3EOR-=9UT_jrJEECzLBfT-DoOt05fg@mail.gmail.com>
	<CALuBA_qxu=nGP93yfPXEdhiUdxBkQ2C7YZx=82i7qbOA=egr+A@mail.gmail.com>
	<CAPhbRDZAnSLP6OYkWUHkvczj-sm4FGaE6apEEoiGRo_D+Z=nww@mail.gmail.com>
	<CALuBA_pfzAOsZf_fU=sN6uGkCdm04iwAwxJyV4r4gEkupSp2HQ@mail.gmail.com>
Message-ID: <CAMw35_oqtZunCh4Bc5FBZi+pP4_WSU8HacTmSosczBoJLubiQw@mail.gmail.com>

At a quick look, the permissions set in the WF11 zip look mostly
appropriate to me. For example, I don't understand why the RPM version
needs to set ugo+r on standalone/configuration/mgmt-groups.properties and
stuff like that.

So I'd vote, they should probably be the same, but i'd rather see a
justification for why the RPM ones were changed, then see those changes go
into WF so they're the same.

Ken

On Mon, Dec 11, 2017 at 7:43 AM Romain Pelisse <belaran at redhat.com> wrote:

> Hi all,
>
> Not too much involvement except from Brian and I :) - sadly, we cannot
> move forward on this topic without a minimum of consensus. If you don't to
> participate, can you at least reply "+1 Brian" (if you think we should NOT
> try to change the current behavior") or "+1 Romain" (if you think we should
> address this issue somehow).
>
> (please don't vote on the PR I've proposed, it's just a proposal on HOW we
> could do it - here I want to assert IF we want to do it, not voting on the
> "how").
>
> On Wed, Dec 6, 2017 at 6:05 PM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>> On Wed, Dec 6, 2017 at 4:27 AM, Romain Pelisse <belaran at redhat.com>
>> wrote:
>>
>>> Hi Brian (and all),
>>>
>>> I honestly understand your resistance, and I'm completely fine if we end
>>> up closing this all issue as WONTDO or REJECTED. I just do want to have a
>>> discussion about it and come back with clear reasons and motivations for
>>> changing or not the privileges of each of those files.
>>>
>>
>> Thanks for doing this! There have been a number of issues filed over the
>> last year or so on this general topic so I'm very happy to see them getting
>> addressed here via the WildFly community. Most of the issues I've been
>> talking about are JBEAP issues in JIRA, which is fine, but the best way to
>> get this solid is to get WildFly the way we want it first.
>>
>> Even on the config file read perms thing I mentioned in my last post, I'm
>> personally resistant to changing it, but my biggest resistance is to doing
>> that without a full community discussion.
>>
>>
>>> Given that we see different things on our local setup, I think the best
>>> will be to use a build on a CI Server and works from what we see there. Is
>>> there an easy way for me to clone a job building Wildfly and tweak it on
>>> some (publicly) accessible instance ?
>>>
>>
>> https://developer.jboss.org/thread/224262 describes how to get a zip
>> built from a daily CI job.
>>
>> If anyone has any insights on this, please speak up!
>>
>>
>>>
>>>
>>> On Mon, Dec 4, 2017 at 6:48 PM, Brian Stansberry <
>>> brian.stansberry at redhat.com> wrote:
>>>
>>>> A slightly different topic, related to the "logging.properties/xml
>>>> config file" topic is whether these files should be world and/or group
>>>> readable.
>>>>
>>>> Changing this has been proposed in the past on the EAP side, primarily
>>>> based on the argument that users could put sensitive data in these files.
>>>> This thread seems like a good time to debate this a bit in community.
>>>>
>>>> I've resisted that primarily on the basis of:
>>>>
>>>> 1) These files or those similarly used have had these perms as far back
>>>> as I can find in JBoss AS. So the odds that some people are relying upon
>>>> those perms is fairly high and we need to assume a change would be a
>>>> breaking change for some people.
>>>>
>>>> 2) Other software I've looked at like Tomcat and httpd have similar
>>>> permission schemes to what we have for their config files, which can also
>>>> potentially include sensitive data.
>>>>
>>>> 3) We provide facilities like the vault or elytron credential store
>>>> refs for keeping sensitive data out of the config files.
>>>>
>>>>
>>>> On Mon, Dec 4, 2017 at 11:38 AM, Brian Stansberry <
>>>> brian.stansberry at redhat.com> wrote:
>>>>
>>>>> Thanks, Romain.
>>>>>
>>>>> Re: what the actual permissions are, FWIW I get what I see on both my
>>>>> macbook and my Fedora 27 machine, both when unzipping the actual
>>>>> 11.0.0.Final and when unzipping the result of a build of master, and both
>>>>> with and without the -Prelease -Pjboss-release args to maven that we
>>>>> include when doing actual releases. Unzipping the zip in build/target
>>>>> doesn't include the jars of course.
>>>>>
>>>>> So it sounds like we need input from others.
>>>>>
>>>>> Re: modules.xml, if you are seeing those as rw-r--r-- as well, then +1
>>>>> to ignoring them in further discussion.
>>>>>
>>>>> Re: logging.properties, those serve a very similar conceptual role to
>>>>> the standalone|host|domain.xml files so I see no reason for them to have
>>>>> different perms. However, you and I are getting different results, where
>>>>> you report them as group writable and I don't. What do you see for the xml
>>>>> config files?
>>>>>
>>>>> Re: RPM changing to match WildFly, that's an EAP discussion, so that
>>>>> can be taken up elsewhere once we have WildFly the way we want it.
>>>>>
>>>>>
>>>>> On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse <belaran at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Brian and all,
>>>>>>
>>>>>> err, my own observation differs from yours. I've rebuild Wildfly from
>>>>>> the last content of the master branch and get the same privileges on the
>>>>>> jboss-modules.jar (so -rw-rw-r-- and not as you are seeing  rwxr--r--).
>>>>>> Same with the domain folder, which turns out on my local system associated
>>>>>> to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a
>>>>>> transcript of what I did - maybe you can spot why our results differs so
>>>>>> much.
>>>>>>
>>>>>> $ git show
>>>>>> commit 46e119c65d9e32bc0ec69f3933267fece959ed3f
>>>>>> Merge: 051f080 c7d9075
>>>>>> Author: Kabir Khan <kkhan at redhat.com>
>>>>>> Date:   Tue Nov 28 17:46:40 2017 +0000
>>>>>>
>>>>>>     Merge pull request #10669 from praxeo/WFLY-9284
>>>>>>
>>>>>>     WFLY-9284 Correct MVN env variable to mvnw.cmd
>>>>>>
>>>>>> $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d
>>>>>> wildfly-12.zip
>>>>>> ...
>>>>>> $ ls -l
>>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov.  11:41
>>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
>>>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/  -d
>>>>>> drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov.  11:41
>>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/
>>>>>>
>>>>>> Checking all the jars in the distribution, they all appears to have
>>>>>> the mask '-rw-rw-r--':
>>>>>>
>>>>>> $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done |
>>>>>> sed -e '/-rw-rw-r--/d'
>>>>>> $
>>>>>>
>>>>>> Regarding properties files, here is the exhaustive list of properties
>>>>>> that RPM packaging has modified the privileges of:
>>>>>>
>>>>>> appclient/configuration/logging.properties rw-------
>>>>>> domain/configuration/application-roles.properties rw-------
>>>>>> domain/configuration/default-server-logging.properties rw-------
>>>>>> domain/configuration/logging.properties rw-------
>>>>>> domain/configuration/mgmt-groups.properties rw-------
>>>>>> standalone/configuration/application-roles.properties rw-------
>>>>>> standalone/configuration/logging.properties rw-------
>>>>>> standalone/configuration/mgmt-groups.properties rw-------
>>>>>>
>>>>>> If I compare that with the content of the extract zip (same fresh
>>>>>> built as above), I can see that 4 files are not having the same mask
>>>>>> (rw------):
>>>>>>
>>>>>> $ for file in $(cut -f1 -d\  ../../../list-props-files.txt ); do ls
>>>>>> -l $file ; done
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>>>>> appclient/configuration/logging.properties
>>>>>> -rw-------. 1 rpelisse rpelisse 710 30 nov.  11:41
>>>>>> domain/configuration/application-roles.properties
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>>>>> domain/configuration/default-server-logging.properties
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>>>>> domain/configuration/logging.properties
>>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>>>>> domain/configuration/mgmt-groups.properties
>>>>>> -rw-------. 1 rpelisse rpelisse 711 30 nov.  11:41
>>>>>> standalone/configuration/application-roles.properties
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>>>>> standalone/configuration/logging.properties
>>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>>>>> standalone/configuration/mgmt-groups.properties
>>>>>>
>>>>>> Now, as you said, those files privileges are indeed fine-grained, so
>>>>>> maybe we can push back to people making the RPM for them to NOT change the
>>>>>> following files privileges:
>>>>>>
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>>>>> appclient/configuration/logging.properties
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>>>>> domain/configuration/default-server-logging.properties
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>>>>> domain/configuration/logging.properties
>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>>>>> standalone/configuration/logging.properties
>>>>>>
>>>>>> However, I don't see the value of letting those files accessible
>>>>>> either group member or any user on the system, but maybe we can make the
>>>>>> argument they should. But the write privileges for group member sounds
>>>>>> wrong to me.
>>>>>>
>>>>>> Also, I'm puzzled Brian and I are seeing different things - am I
>>>>>> looking at the correct zipfile here ?
>>>>>>
>>>>>> Note: You also mention the module.xml - as far as I can see from the
>>>>>> diff provided with issue JBEAP-12374, I don't see any issue with privileges
>>>>>> regarding those files, so we can remove them of the discussion. The only
>>>>>> changes we need to discuss is removing the 'write' privileges' for the
>>>>>> group on jars, reducing the scope of permissions on (some) folders, and
>>>>>> privileges on (some) properties files. So, module.xml are out of the scope.
>>>>>>
>>>>>> On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry <
>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>
>>>>>>> Seems I forgot to "Reply to All" yesterday. The following was meant
>>>>>>> to be sent to wildfly-dev.
>>>>>>>
>>>>>>> On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry <
>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>
>>>>>>>> Before getting into the specifics, first a general note re: perms.
>>>>>>>>
>>>>>>>> Our general permission set for is rwxr-xr-x for directories and
>>>>>>>> rwxr--r-- for files. If someone thinks that's wrong in general; speak up.
>>>>>>>> ;). Otherwise I think any deviation from that we should justify. Not that
>>>>>>>> deviations are wrong, just that they need to have a reason.
>>>>>>>>
>>>>>>>> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <belaran at redhat.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Well, the diff is between the RPM and the zipfile is pretty long,
>>>>>>>>> but it boils down to the 3 set of differences I've pointed out on
>>>>>>>>> WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574>
>>>>>>>>>
>>>>>>>>>    - *.properties and .jar* files are associated with the mask
>>>>>>>>>    rw-rw-r-- giving access to it to any other users and allowing group member
>>>>>>>>>    to modify the file - the RPM distribution fixes that by removing the write
>>>>>>>>>    privileges for the group (rw-r--r--). I personnaly don't see the value of
>>>>>>>>>    letting the group members modify those files, I just can see how this could
>>>>>>>>>    be exploited, so I would say it falls into "clearly wrong and not our
>>>>>>>>>    intent". A case might be made for the .properties files, but for jars file
>>>>>>>>>    I really don't see a valid use case (unless of course, any of you know one)
>>>>>>>>>    ;
>>>>>>>>>
>>>>>>>>> There are a few different things here, so let's deal with them
>>>>>>>> separately.
>>>>>>>>
>>>>>>>> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them as
>>>>>>>> rwxr--r--. Which seems correct to me. In case I'm seeing something wrong, I
>>>>>>>> don't see why they should vary from the general standard. And the
>>>>>>>> module.xml file should be consistent, since there's not much point in
>>>>>>>> locking people from touching jars but letting them change what jars get
>>>>>>>> loaded.
>>>>>>>>
>>>>>>>> For properties files, let's consider them on a more fine-grained
>>>>>>>> basis. For example, the properties files used by the security realms have
>>>>>>>> different kinds of data than logging.properties does.
>>>>>>>>
>>>>>>>> The perms on the security realm property files are rw-------, not
>>>>>>>> rw-rw-r--.
>>>>>>>>
>>>>>>>> The logging.properties files are rw-r--r-- which is consistent with
>>>>>>>> the domain|host|standalone.xml files and with the general standard.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>    -
>>>>>>>>>    - *some directories* like 'domain/tmp/auth' have too
>>>>>>>>>    restrictive mask like rwx------ and RPMS to turned them into rwxrwxr-x
>>>>>>>>>    (that I don't really agree with) and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    - *other directories*, likes 'domain' have again a too
>>>>>>>>>    permissive mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make
>>>>>>>>>    senses.
>>>>>>>>>
>>>>>>>>> In the unzip I see these directories as rwxr-xr-x, which I think
>>>>>>>> is fine.
>>>>>>>>
>>>>>>>> Are you concerned with any other directories besides
>>>>>>>> $JBOSS_HOME/domain and $JBOSS_HOME/standalone?
>>>>>>>>
>>>>>>>>> So we need to find an agreement on those three items, and then see
>>>>>>>>> how we proceed to implement the fix (if needed).
>>>>>>>>>
>>>>>>>>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry <
>>>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> I think we need to start with the assumption that the permissions
>>>>>>>>>> we have in the zip are the way they are for a reason and evaluate possible
>>>>>>>>>> changes based on discussion here of each type of change. Maybe the RPM
>>>>>>>>>> settings are better, maybe they are not. Or maybe they are better but the
>>>>>>>>>> improvement is not worth the disruption a change may cause to our end
>>>>>>>>>> users, who may rely on the current zip settings. Or maybe what we have in
>>>>>>>>>> the zip is clearly wrong and doesn't follow our own intent. I expect we'll
>>>>>>>>>> probably see a little of each category, although hopefully some changes for
>>>>>>>>>> WF 11 removed the "clearly wrong and doesn't follow our intent" cases. :)
>>>>>>>>>>
>>>>>>>>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <
>>>>>>>>>> belaran at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> As reported on JBEAP-12374[1], there is some discrepancies
>>>>>>>>>>> between the ZIP file we provided for Widlfy/EAP and the RPM generate. Most
>>>>>>>>>>> of those discrepancies - or the most relevant ones, are some fine tuning
>>>>>>>>>>> performed on the (POSIX) privileges (things such as removing the write
>>>>>>>>>>> privilege for member of the same group as the owner of the file).
>>>>>>>>>>>
>>>>>>>>>>> I've looked into this and because those files are produced by
>>>>>>>>>>> our own Maven plugin (as part of wildfly-build-tools), we can not simply
>>>>>>>>>>> modify the assembly.xml. Which actually is probably for the best, as it
>>>>>>>>>>> would made the assembly file quite cumbersome.
>>>>>>>>>>>
>>>>>>>>>>> Anyhow, I've worked on a proposal[2] for the
>>>>>>>>>>> wildfly-build-tools, but when I reported the problem on WFLY-9574[3], Brian
>>>>>>>>>>> suggested I started a discussion here. So does anyone have a (strong)
>>>>>>>>>>> opinion about this issue and/or how to resolve it ? :)
>>>>>>>>>>>
>>>>>>>>>>> (For the record, I do think it is best to fix the privileges to
>>>>>>>>>>> follow what the RPM does for us for now, but if you feel this issue should
>>>>>>>>>>> not be addressed, and dev- the issue, I'm certainly not opposed to it
>>>>>>>>>>> either).
>>>>>>>>>>>
>>>>>>>>>>> [1] https://issues.jboss.org/browse/JBEAP-12374
>>>>>>>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40
>>>>>>>>>>> [3] https://issues.jboss.org/browse/WFLY-9574
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Brian Stansberry
>>>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>>>> Red Hat
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Brian Stansberry
>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>> Red Hat
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Brian Stansberry
>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>> Red Hat
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Manager, Senior Principal Software Engineer
>>>>> Red Hat
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Manager, Senior Principal Software Engineer
>>>> Red Hat
>>>>
>>>
>>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> 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/20171212/ba09a80d/attachment-0001.html 

From david.lloyd at redhat.com  Tue Dec 12 14:53:05 2017
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 12 Dec 2017 13:53:05 -0600
Subject: [wildfly-dev] Run level as a factor for capabilities and
	requirements?
In-Reply-To: <CAPhbRDbKDJbH+LgL7emM4we0m2sW-0CEigxjZvzeAmX0OzF_hg@mail.gmail.com>
References: <CAPhbRDbKDJbH+LgL7emM4we0m2sW-0CEigxjZvzeAmX0OzF_hg@mail.gmail.com>
Message-ID: <CANghgrT70-gDgz=qo0OaqLD0vjyfnRYSY=-kboz3XmAYvx-5cA@mail.gmail.com>

On Tue, Dec 12, 2017 at 11:15 AM, Brian Stansberry
<brian.stansberry at redhat.com> wrote:
> Something the current capabilities/requirements stuff doesn't handle is the
> fact that some capabilities can be configured but won't be turned on in some
> situations (i.e. admin-only). Which means other capabilities that might
> require them and that are present in admin-only will pass configuration
> consistency checks but will fail at runtime.
>
> I'm not sure what to do about this. Some off the top of my head thoughts:
>
> 1) The capability description data on wildly-capabilities includes something
> about this, so people who want to require the capability understand whether
> it can be required.
>
> This is easy, and helps avoids future bugs. It's just documentation so it
> does nothing about the actual server behavior.
>
> 2) The registration for capabilities could include "minimal running-mode"
> data, and then the capability resolution could check that and fail if it
> finds a mismatch in the current running mode.

I'm inclined towards this option.  But...

> This is more work obviously. It may help surface problems earlier, i.e. make
> it more likely that a testsuite catches a mismatch in time to correct it
> before a .Final release. It would also have the minor benefit of perhaps
> providing a better error message for a user who configures a mismatch.

It'd be best if we can detect this more up front if possible.  If this
kind of mismatch occurs, I think it would never be the user's fault.

--
- DML

From jperkins at redhat.com  Tue Dec 12 15:12:25 2017
From: jperkins at redhat.com (James Perkins)
Date: Tue, 12 Dec 2017 12:12:25 -0800
Subject: [wildfly-dev] WFLY-9574 - Distribution files does not have
 POSIX permissions perfectly set
In-Reply-To: <CADGwLpiC9+9ESBFwMGrCD_OYPHr_7+U5+Qmi6Ne6cVkNViv7EQ@mail.gmail.com>
References: <CALuBA_p5Mqag2+TSD9bUWGM5BgDpirdZC7zvL5OE8w-HfA4AWw@mail.gmail.com>
	<CAPhbRDYyGwNpqFq8bYdRk53_hx6Mg4yHwOcmmYYnwDp_3-B+_A@mail.gmail.com>
	<CALuBA_pSvfNYPug1byQrS7Bic45vVvvdQ4Mjd-BQ6Pa4t5m05g@mail.gmail.com>
	<CAPhbRDYnYLd-SXuE_m_2b14W9VwNhy08KDpC0MdP6n3mipMi0A@mail.gmail.com>
	<CAPhbRDZFTd52gO8-psaaXJSVNAPn=3MtjA3XuyEC501Hj-rRJw@mail.gmail.com>
	<CALuBA_pXT89PNspojT-sT3GNTVhf1R1F7YJPxn7K-B6dmP4+bg@mail.gmail.com>
	<CAPhbRDZFfcuS5kZNHU99cVDSTjewsVynuaZAAxsxdQSswxOZOA@mail.gmail.com>
	<CAPhbRDYN_PGP8fo6BizQ3EOR-=9UT_jrJEECzLBfT-DoOt05fg@mail.gmail.com>
	<CALuBA_qxu=nGP93yfPXEdhiUdxBkQ2C7YZx=82i7qbOA=egr+A@mail.gmail.com>
	<CAPhbRDZAnSLP6OYkWUHkvczj-sm4FGaE6apEEoiGRo_D+Z=nww@mail.gmail.com>
	<CALuBA_pfzAOsZf_fU=sN6uGkCdm04iwAwxJyV4r4gEkupSp2HQ@mail.gmail.com>
	<CADGwLphZ9wWbLh87qrDihpeFzKumGFnkabcq1FzwkWSTRrE6vA@mail.gmail.com>
	<0ec575db-fa44-dd31-73a6-766ec0edc7a8@redhat.com>
	<CADGwLpiC9+9ESBFwMGrCD_OYPHr_7+U5+Qmi6Ne6cVkNViv7EQ@mail.gmail.com>
Message-ID: <CADGwLphPuUMT5uBYrYRJ4Jq+kjjKCJs8aG=6=wCcS1CSkkUsBA@mail.gmail.com>

My apologies after rereading the comment I think you're just saying
permissions need to be consistent across all deliverables which I agree
with. Sorry for the confusion.

On Tue, Dec 12, 2017 at 8:47 AM, James Perkins <jperkins at redhat.com> wrote:

> That means the packaging tool has to know about all the files it consumes.
> That would make the feature pack concept irrelevant. There could be a
> reason the feature pack set specific permissions on a file and the
> provisioning tool should honor that. It shouldn't be making assumptions.
> Especially if that assumption is determined by a file extension.
>
> On Tue, Dec 12, 2017 at 12:20 AM, Carlo de Wolf <cdewolf at redhat.com>
> wrote:
>
>> If any target platform needs more restrictive permissions, those need to
>> apply to all deliverables (whether it is ZIP or RPMs).
>>
>> Carlo
>>
>>
>> On 11-12-17 23:28, James Perkins wrote:
>>
>> I personally don't have any strong opinions on what the permissions
>> should be. However as I said before it should definitely not be the
>> provisioning plugin that sets these permissions. If they need to be
>> different we need to change them in the feature pack.
>>
>> On Mon, Dec 11, 2017 at 4:47 AM, Romain Pelisse <belaran at redhat.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> Not too much involvement except from Brian and I :) - sadly, we cannot
>>> move forward on this topic without a minimum of consensus. If you don't to
>>> participate, can you at least reply "+1 Brian" (if you think we should NOT
>>> try to change the current behavior") or "+1 Romain" (if you think we should
>>> address this issue somehow).
>>>
>>> (please don't vote on the PR I've proposed, it's just a proposal on HOW
>>> we could do it - here I want to assert IF we want to do it, not voting on
>>> the "how").
>>>
>>> On Wed, Dec 6, 2017 at 6:05 PM, Brian Stansberry <
>>> brian.stansberry at redhat.com> wrote:
>>>
>>>> On Wed, Dec 6, 2017 at 4:27 AM, Romain Pelisse <belaran at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi Brian (and all),
>>>>>
>>>>> I honestly understand your resistance, and I'm completely fine if we
>>>>> end up closing this all issue as WONTDO or REJECTED. I just do want to have
>>>>> a discussion about it and come back with clear reasons and motivations for
>>>>> changing or not the privileges of each of those files.
>>>>>
>>>>
>>>> Thanks for doing this! There have been a number of issues filed over
>>>> the last year or so on this general topic so I'm very happy to see them
>>>> getting addressed here via the WildFly community. Most of the issues I've
>>>> been talking about are JBEAP issues in JIRA, which is fine, but the best
>>>> way to get this solid is to get WildFly the way we want it first.
>>>>
>>>> Even on the config file read perms thing I mentioned in my last post,
>>>> I'm personally resistant to changing it, but my biggest resistance is to
>>>> doing that without a full community discussion.
>>>>
>>>>
>>>>> Given that we see different things on our local setup, I think the
>>>>> best will be to use a build on a CI Server and works from what we see
>>>>> there. Is there an easy way for me to clone a job building Wildfly and
>>>>> tweak it on some (publicly) accessible instance ?
>>>>>
>>>>
>>>> https://developer.jboss.org/thread/224262 describes how to get a zip
>>>> built from a daily CI job.
>>>>
>>>> If anyone has any insights on this, please speak up!
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Mon, Dec 4, 2017 at 6:48 PM, Brian Stansberry <
>>>>> brian.stansberry at redhat.com> wrote:
>>>>>
>>>>>> A slightly different topic, related to the "logging.properties/xml
>>>>>> config file" topic is whether these files should be world and/or group
>>>>>> readable.
>>>>>>
>>>>>> Changing this has been proposed in the past on the EAP side,
>>>>>> primarily based on the argument that users could put sensitive data in
>>>>>> these files. This thread seems like a good time to debate this a bit in
>>>>>> community.
>>>>>>
>>>>>> I've resisted that primarily on the basis of:
>>>>>>
>>>>>> 1) These files or those similarly used have had these perms as far
>>>>>> back as I can find in JBoss AS. So the odds that some people are relying
>>>>>> upon those perms is fairly high and we need to assume a change would be a
>>>>>> breaking change for some people.
>>>>>>
>>>>>> 2) Other software I've looked at like Tomcat and httpd have similar
>>>>>> permission schemes to what we have for their config files, which can also
>>>>>> potentially include sensitive data.
>>>>>>
>>>>>> 3) We provide facilities like the vault or elytron credential store
>>>>>> refs for keeping sensitive data out of the config files.
>>>>>>
>>>>>>
>>>>>> On Mon, Dec 4, 2017 at 11:38 AM, Brian Stansberry <
>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>
>>>>>>> Thanks, Romain.
>>>>>>>
>>>>>>> Re: what the actual permissions are, FWIW I get what I see on both
>>>>>>> my macbook and my Fedora 27 machine, both when unzipping the actual
>>>>>>> 11.0.0.Final and when unzipping the result of a build of master, and both
>>>>>>> with and without the -Prelease -Pjboss-release args to maven that we
>>>>>>> include when doing actual releases. Unzipping the zip in build/target
>>>>>>> doesn't include the jars of course.
>>>>>>>
>>>>>>> So it sounds like we need input from others.
>>>>>>>
>>>>>>> Re: modules.xml, if you are seeing those as rw-r--r-- as well, then
>>>>>>> +1 to ignoring them in further discussion.
>>>>>>>
>>>>>>> Re: logging.properties, those serve a very similar conceptual role
>>>>>>> to the standalone|host|domain.xml files so I see no reason for them to have
>>>>>>> different perms. However, you and I are getting different results, where
>>>>>>> you report them as group writable and I don't. What do you see for the xml
>>>>>>> config files?
>>>>>>>
>>>>>>> Re: RPM changing to match WildFly, that's an EAP discussion, so that
>>>>>>> can be taken up elsewhere once we have WildFly the way we want it.
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Dec 1, 2017 at 4:11 AM, Romain Pelisse <belaran at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Brian and all,
>>>>>>>>
>>>>>>>> err, my own observation differs from yours. I've rebuild Wildfly
>>>>>>>> from the last content of the master branch and get the same privileges on
>>>>>>>> the jboss-modules.jar (so -rw-rw-r-- and not as you are seeing  rwxr--r--).
>>>>>>>> Same with the domain folder, which turns out on my local system associated
>>>>>>>> to 'drwxrwxr-x.' and not 'rwxr-xr-x' as you are seeing). See below for a
>>>>>>>> transcript of what I did - maybe you can spot why our results differs so
>>>>>>>> much.
>>>>>>>>
>>>>>>>> $ git show
>>>>>>>> commit 46e119c65d9e32bc0ec69f3933267fece959ed3f
>>>>>>>> Merge: 051f080 c7d9075
>>>>>>>> Author: Kabir Khan <kkhan at redhat.com>
>>>>>>>> Date:   Tue Nov 28 17:46:40 2017 +0000
>>>>>>>>
>>>>>>>>     Merge pull request #10669 from praxeo/WFLY-9284
>>>>>>>>
>>>>>>>>     WFLY-9284 Correct MVN env variable to mvnw.cmd
>>>>>>>>
>>>>>>>> $ unzip ./build/target/wildfly-12.0.0.Alpha1-SNAPSHOT.zip -d
>>>>>>>> wildfly-12.zip
>>>>>>>> ...
>>>>>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.
>>>>>>>> Alpha1-SNAPSHOT/jboss-modules.jar
>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 403683 30 nov.  11:41
>>>>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/jboss-modules.jar
>>>>>>>> $ ls -l wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/  -d
>>>>>>>> drwxrwxr-x. 5 rpelisse rpelisse 4096 30 nov.  11:41
>>>>>>>> wildfly-12.zip/wildfly-12.0.0.Alpha1-SNAPSHOT/domain/
>>>>>>>>
>>>>>>>> Checking all the jars in the distribution, they all appears to have
>>>>>>>> the mask '-rw-rw-r--':
>>>>>>>>
>>>>>>>> $ for jar in $(find dist/ -name *.jar); do ls -l "${jar}" ; done |
>>>>>>>> sed -e '/-rw-rw-r--/d'
>>>>>>>> $
>>>>>>>>
>>>>>>>> Regarding properties files, here is the exhaustive list of
>>>>>>>> properties that RPM packaging has modified the privileges of:
>>>>>>>>
>>>>>>>> appclient/configuration/logging.properties rw-------
>>>>>>>> domain/configuration/application-roles.properties rw-------
>>>>>>>> domain/configuration/default-server-logging.properties rw-------
>>>>>>>> domain/configuration/logging.properties rw-------
>>>>>>>> domain/configuration/mgmt-groups.properties rw-------
>>>>>>>> standalone/configuration/application-roles.properties rw-------
>>>>>>>> standalone/configuration/logging.properties rw-------
>>>>>>>> standalone/configuration/mgmt-groups.properties rw-------
>>>>>>>>
>>>>>>>> If I compare that with the content of the extract zip (same fresh
>>>>>>>> built as above), I can see that 4 files are not having the same mask
>>>>>>>> (rw------):
>>>>>>>>
>>>>>>>> $ for file in $(cut -f1 -d\  ../../../list-props-files.txt ); do ls
>>>>>>>> -l $file ; done
>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>>>>>>> appclient/configuration/logging.properties
>>>>>>>> -rw-------. 1 rpelisse rpelisse 710 30 nov.  11:41
>>>>>>>> domain/configuration/application-roles.properties
>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>>>>>>> domain/configuration/default-server-logging.properties
>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>>>>>>> domain/configuration/logging.properties
>>>>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>>>>>>> domain/configuration/mgmt-groups.properties
>>>>>>>> -rw-------. 1 rpelisse rpelisse 711 30 nov.  11:41
>>>>>>>> standalone/configuration/application-roles.properties
>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>>>>>>> standalone/configuration/logging.properties
>>>>>>>> -rw-------. 1 rpelisse rpelisse 669 30 nov.  11:41
>>>>>>>> standalone/configuration/mgmt-groups.properties
>>>>>>>>
>>>>>>>> Now, as you said, those files privileges are indeed fine-grained,
>>>>>>>> so maybe we can push back to people making the RPM for them to NOT change
>>>>>>>> the following files privileges:
>>>>>>>>
>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2314 30 nov.  11:41
>>>>>>>> appclient/configuration/logging.properties
>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 1528 30 nov.  11:41
>>>>>>>> domain/configuration/default-server-logging.properties
>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2328 30 nov.  11:41
>>>>>>>> domain/configuration/logging.properties
>>>>>>>> -rw-rw-r--. 1 rpelisse rpelisse 2395 30 nov.  11:41
>>>>>>>> standalone/configuration/logging.properties
>>>>>>>>
>>>>>>>> However, I don't see the value of letting those files accessible
>>>>>>>> either group member or any user on the system, but maybe we can make the
>>>>>>>> argument they should. But the write privileges for group member sounds
>>>>>>>> wrong to me.
>>>>>>>>
>>>>>>>> Also, I'm puzzled Brian and I are seeing different things - am I
>>>>>>>> looking at the correct zipfile here ?
>>>>>>>>
>>>>>>>> Note: You also mention the module.xml - as far as I can see from
>>>>>>>> the diff provided with issue JBEAP-12374, I don't see any issue with
>>>>>>>> privileges regarding those files, so we can remove them of the discussion.
>>>>>>>> The only changes we need to discuss is removing the 'write' privileges' for
>>>>>>>> the group on jars, reducing the scope of permissions on (some) folders, and
>>>>>>>> privileges on (some) properties files. So, module.xml are out of the scope.
>>>>>>>>
>>>>>>>> On Thu, Nov 30, 2017 at 7:17 PM, Brian Stansberry <
>>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> Seems I forgot to "Reply to All" yesterday. The following was
>>>>>>>>> meant to be sent to wildfly-dev.
>>>>>>>>>
>>>>>>>>> On Wed, Nov 29, 2017 at 10:04 AM, Brian Stansberry <
>>>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> Before getting into the specifics, first a general note re: perms.
>>>>>>>>>>
>>>>>>>>>> Our general permission set for is rwxr-xr-x for directories and
>>>>>>>>>> rwxr--r-- for files. If someone thinks that's wrong in general; speak up.
>>>>>>>>>> ;). Otherwise I think any deviation from that we should justify. Not that
>>>>>>>>>> deviations are wrong, just that they need to have a reason.
>>>>>>>>>>
>>>>>>>>>> On Wed, Nov 29, 2017 at 3:12 AM, Romain Pelisse <
>>>>>>>>>> belaran at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Well, the diff is between the RPM and the zipfile is pretty
>>>>>>>>>>> long, but it boils down to the 3 set of differences I've pointed out on
>>>>>>>>>>> WFLY-9574: <https://issues.jboss.org/browse/WFLY-9574>
>>>>>>>>>>>
>>>>>>>>>>>    - *.properties and .jar* files are associated with the mask
>>>>>>>>>>>    rw-rw-r-- giving access to it to any other users and allowing group member
>>>>>>>>>>>    to modify the file - the RPM distribution fixes that by removing the write
>>>>>>>>>>>    privileges for the group (rw-r--r--). I personnaly don't see the value of
>>>>>>>>>>>    letting the group members modify those files, I just can see how this could
>>>>>>>>>>>    be exploited, so I would say it falls into "clearly wrong and not our
>>>>>>>>>>>    intent". A case might be made for the .properties files, but for jars file
>>>>>>>>>>>    I really don't see a valid use case (unless of course, any of you know one)
>>>>>>>>>>>    ;
>>>>>>>>>>>
>>>>>>>>>>> There are a few different things here, so let's deal with them
>>>>>>>>>> separately.
>>>>>>>>>>
>>>>>>>>>> For jars, with an unzip of wildfly-11.0.0.Final.zip, I see them
>>>>>>>>>> as rwxr--r--. Which seems correct to me. In case I'm seeing something
>>>>>>>>>> wrong, I don't see why they should vary from the general standard. And the
>>>>>>>>>> module.xml file should be consistent, since there's not much point in
>>>>>>>>>> locking people from touching jars but letting them change what jars get
>>>>>>>>>> loaded.
>>>>>>>>>>
>>>>>>>>>> For properties files, let's consider them on a more fine-grained
>>>>>>>>>> basis. For example, the properties files used by the security realms have
>>>>>>>>>> different kinds of data than logging.properties does.
>>>>>>>>>>
>>>>>>>>>> The perms on the security realm property files are rw-------, not
>>>>>>>>>> rw-rw-r--.
>>>>>>>>>>
>>>>>>>>>> The logging.properties files are rw-r--r-- which is consistent
>>>>>>>>>> with the domain|host|standalone.xml files and with the general standard.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>    -
>>>>>>>>>>>    - *some directories* like 'domain/tmp/auth' have too
>>>>>>>>>>>    restrictive mask like rwx------ and RPMS to turned them into rwxrwxr-x
>>>>>>>>>>>    (that I don't really agree with) and
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>    - *other directories*, likes 'domain' have again a too
>>>>>>>>>>>    permissive mask rwxrwxr-x (should be rwxr-xr-x) - and this IMHO, make
>>>>>>>>>>>    senses.
>>>>>>>>>>>
>>>>>>>>>>> In the unzip I see these directories as rwxr-xr-x, which I think
>>>>>>>>>> is fine.
>>>>>>>>>>
>>>>>>>>>> Are you concerned with any other directories besides
>>>>>>>>>> $JBOSS_HOME/domain and $JBOSS_HOME/standalone?
>>>>>>>>>>
>>>>>>>>>>> So we need to find an agreement on those three items, and then
>>>>>>>>>>> see how we proceed to implement the fix (if needed).
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 28, 2017 at 10:00 PM, Brian Stansberry <
>>>>>>>>>>> brian.stansberry at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I think we need to start with the assumption that the
>>>>>>>>>>>> permissions we have in the zip are the way they are for a reason and
>>>>>>>>>>>> evaluate possible changes based on discussion here of each type of change.
>>>>>>>>>>>> Maybe the RPM settings are better, maybe they are not. Or maybe they are
>>>>>>>>>>>> better but the improvement is not worth the disruption a change may cause
>>>>>>>>>>>> to our end users, who may rely on the current zip settings. Or maybe what
>>>>>>>>>>>> we have in the zip is clearly wrong and doesn't follow our own intent. I
>>>>>>>>>>>> expect we'll probably see a little of each category, although hopefully
>>>>>>>>>>>> some changes for WF 11 removed the "clearly wrong and doesn't follow our
>>>>>>>>>>>> intent" cases. :)
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Nov 28, 2017 at 8:37 AM, Romain Pelisse <
>>>>>>>>>>>> belaran at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> As reported on JBEAP-12374[1], there is some discrepancies
>>>>>>>>>>>>> between the ZIP file we provided for Widlfy/EAP and the RPM generate. Most
>>>>>>>>>>>>> of those discrepancies - or the most relevant ones, are some fine tuning
>>>>>>>>>>>>> performed on the (POSIX) privileges (things such as removing the write
>>>>>>>>>>>>> privilege for member of the same group as the owner of the file).
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've looked into this and because those files are produced by
>>>>>>>>>>>>> our own Maven plugin (as part of wildfly-build-tools), we can not simply
>>>>>>>>>>>>> modify the assembly.xml. Which actually is probably for the best, as it
>>>>>>>>>>>>> would made the assembly file quite cumbersome.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Anyhow, I've worked on a proposal[2] for the
>>>>>>>>>>>>> wildfly-build-tools, but when I reported the problem on WFLY-9574[3], Brian
>>>>>>>>>>>>> suggested I started a discussion here. So does anyone have a (strong)
>>>>>>>>>>>>> opinion about this issue and/or how to resolve it ? :)
>>>>>>>>>>>>>
>>>>>>>>>>>>> (For the record, I do think it is best to fix the privileges
>>>>>>>>>>>>> to follow what the RPM does for us for now, but if you feel this issue
>>>>>>>>>>>>> should not be addressed, and dev- the issue, I'm certainly not opposed to
>>>>>>>>>>>>> it either).
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] https://issues.jboss.org/browse/JBEAP-12374
>>>>>>>>>>>>> [2] https://github.com/wildfly/wildfly-build-tools/pull/40
>>>>>>>>>>>>> [3] https://issues.jboss.org/browse/WFLY-9574
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> wildfly-dev mailing list
>>>>>>>>>>>>> wildfly-dev at lists.jboss.org
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Brian Stansberry
>>>>>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>>>>>> Red Hat
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Brian Stansberry
>>>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>>>> Red Hat
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Brian Stansberry
>>>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>>>> Red Hat
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Brian Stansberry
>>>>>>> Manager, Senior Principal Software Engineer
>>>>>>> Red Hat
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Brian Stansberry
>>>>>> Manager, Senior Principal Software Engineer
>>>>>> Red Hat
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Manager, Senior Principal Software Engineer
>>>> Red Hat
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>> _______________________________________________
>> wildfly-dev mailing listwildfly-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
>



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

From jperkins at redhat.com  Tue Dec 12 15:18:37 2017
From: jperkins at redhat.com (James Perkins)
Date: Tue, 12 Dec 2017 12:18:37 -0800
Subject: [wildfly-dev] Logging Changes
In-Reply-To: <CAPhbRDYG5gVLWPOTODiO0Wd5te57xJA2+zJyF6joNnB__ZcuDg@mail.gmail.com>
References: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
	<CANghgrRrbV_ksi8FBOSQthc1XLsVrc-sNyBGz69tJFgD00GFiQ@mail.gmail.com>
	<CAPhbRDYr1yV1NVGxiuteM9wHnEZZE8PKzS7yD8mnCg1-EswWaQ@mail.gmail.com>
	<CADGwLpgfOhDfW_yE21=EdN5aA75qZNKYoSz=xdHXsYXQP+WqTw@mail.gmail.com>
	<CAPhbRDYG5gVLWPOTODiO0Wd5te57xJA2+zJyF6joNnB__ZcuDg@mail.gmail.com>
Message-ID: <CADGwLpgdeiPmxsda=26xi0_Rq1vj3axh-Bxa8qULpF9_SZGzog@mail.gmail.com>

On Tue, Dec 12, 2017 at 11:10 AM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:
>
>
>>>> I'm not sure what counts as first in this context, but fwiw if a
>>> logging subsystem is present during boot we always execute it's
>>> Stage.RUNTIME steps first before proceeding on to doing the parallel
>>> execution of the other subsystems. We could probably without too much
>>> trouble get a bit more grimy, e.g. to get the subsystem ops to run before a
>>> few others if they don't already. Beyond that I sense we wouldn't be
>>> talking grimy, we'd be talking horrible. :)
>>>
>>
>> Darran and I had a brief discussion about what we could do because at
>> least parts of Elytron and logging are generally needed before other things
>> are configured. Elytron would likely need to be first because logging will
>> have to use capabilities from it.
>>
>> I've wondered if there should be a new Stage.PRE_RUNTIME type of stage,
>> but I can also see where that may get abused.
>>
>
> This is starting to smell bad.
>
> Elytron needs DS it seems, and DS needs ? and, well, this is why we use
> MSC. :)  We hadn't had deps from logging to other subsystems before, which
> is what made the minor boot op ordering tricks we do useful, but since we
> now do, then we're really down to MSC. Boot op ordering tricks can help
> optimize common cases like a logging subsystem not having elytron
> dependencies, but I don't think we should try and create a duplicate MSC.
>
>

Yes I definitely agree. I don't really think adding a new stage is a good
idea.

The only real reason for logging to need a dependency on Elytron would be
to get an SSLContext for sending log messages over a socket. We don't
currently have a socket-handler and the syslog handler doesn't currently
support SSL. However the syslog server for access logging does.

If we don't want to have logging rely on Elytron we'd just have to use the
standard way of configuring an SSLContext.


> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>



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

From stuart.w.douglas at gmail.com  Tue Dec 12 16:24:45 2017
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 13 Dec 2017 08:24:45 +1100
Subject: [wildfly-dev] GRPC subsystem proof of concept
In-Reply-To: <CAF1-sp4372jseCi0vDyV4gVTcvCiqjbDvQ1usUy2EP484qa=GA@mail.gmail.com>
References: <CAAoo=c5XKAs5=u5shjA=p-puAqu0+HtS14U+f_KjqVVqH1_urg@mail.gmail.com>
	<CAMxVf4PWkB1JJ97mHRYvrYeT8nFj0EaAYa612BJVNSnzAkVdww@mail.gmail.com>
	<CAF1-sp4372jseCi0vDyV4gVTcvCiqjbDvQ1usUy2EP484qa=GA@mail.gmail.com>
Message-ID: <CAAoo=c40DL9hKa9RxSaASMozFXZ940W5BDk82ajrWDhB65v0qQ@mail.gmail.com>

Not without writing a new protobuf compiler, the compiler does not provide
any places to hook into the registration process, the only way I could
manage to do it was to subclass the generated class with a proxy. Protobuf
generates a fair bit of code for each class anyway, so I don't think the
proxy will add much percentage wise.

Stuart

On Wed, Dec 13, 2017 at 1:30 AM, Andrig Miller <anmiller at redhat.com> wrote:

> Stuart,
>
>       Because I have memory footprint on the brain, pretty much all the
> time now, I wonder if you can change your approach in a way that would
> lessen MetaSpace usage.  MetaSpace usage is usually the second largest
> memory hog in Wildfly/EAP, and under certain circumstances it can be larger
> than heap, when the right JVM settings are used to control heap usage (part
> of my presentation in 30 minutes).
>
> Andy
>
> On Tue, Dec 12, 2017 at 3:48 AM, Darran Lofthouse <
> darran.lofthouse at jboss.com> wrote:
>
>> On the security question, if we are interested in pursuing this we will
>> get an analysis document started to look at the options we have for
>> integration with our security implementation.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>>
>> On Mon, 11 Dec 2017 at 05:17 Stuart Douglas <stuart.w.douglas at gmail.com>
>> wrote:
>>
>>> Hi everyone,
>>>
>>> I have done up a proof of concept of GRPC support in Wildfly, which can
>>> be found at [1]. GRPC is an RPC protocol designed by Google, that allows
>>> for easy cross platform invocations.
>>>
>>> My proof of concept uses an Undertow based port of GRPC [2] and
>>> basically works as follows:
>>>
>>> - At deployment time Jandex is used to find all non-abstract classes
>>> that implement io.grpc.BindableService
>>> - I scan the class hierarchy of these classes to find the protobuf
>>> generated base class, and create a subclass of this class using
>>> ProxyFactory, overriding every method except bindService().
>>> - An instance/proxy is created using the ComponentRegistry to do the
>>> creation, and the generated proxy delegates all incoming calls to this
>>> instance
>>> - At runtime any incoming HTTP/2 requests with a type of
>>> application/grpc are intercepted, and passed through this newly created
>>> proxy.
>>>
>>> Basically this means that all you need to do as an application developer
>>> is define your GRPC endpoints using protobuf, implement the classes
>>> generated by the protobuf compiler and then include them in your
>>> application, and Wildfly will do the rest. CDI and EJB annotations on your
>>> GRPC services should work as normal, for example if you put @Stateless on
>>> an endpoint it should work as expected with a SFSB handling all invocations.
>>>
>>> Note that this is a very early stage POC, and lots of stuff is missing
>>> (most notably security).
>>>
>>> Before I go to much further though I though that I should get some
>>> feedback, e.g.
>>>
>>> - Do we actually want this? I am not sure how much interest there is,
>>> but it seems like GRPC could be very useful in a polyglot microservice
>>> environment.
>>> - Is the current implementation the best way of actually registering
>>> GRPC services, or should we require some kind of defining annotation
>>> - What security mechanisms should we support? Out of the box standard
>>> GRPC is fairly limited
>>> - What do we do about transactions? I am leaning towards not supporting
>>> them over GRPC, as we already have solutions for Java invocation in the
>>> form of our EJB protocol, and I think non-Java clients are unlikely to want
>>> to use this.
>>>
>>> Stuart
>>>
>>> [1] https://github.com/stuartwdouglas/wildfly/tree/grpc
>>> [2] https://github.com/stuartwdouglas/undertow-grpc
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Andrig (Andy) T. Miller
> Global Platform Director, Middleware
> Red Hat, Inc.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171213/96447fa0/attachment.html 

From darran.lofthouse at jboss.com  Wed Dec 13 08:11:09 2017
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 13 Dec 2017 13:11:09 +0000
Subject: [wildfly-dev] Run level as a factor for capabilities and
	requirements?
In-Reply-To: <CANghgrT70-gDgz=qo0OaqLD0vjyfnRYSY=-kboz3XmAYvx-5cA@mail.gmail.com>
References: <CAPhbRDbKDJbH+LgL7emM4we0m2sW-0CEigxjZvzeAmX0OzF_hg@mail.gmail.com>
	<CANghgrT70-gDgz=qo0OaqLD0vjyfnRYSY=-kboz3XmAYvx-5cA@mail.gmail.com>
Message-ID: <CAMxVf4PFYNueunGjkV6fjHFqDDqZkgATkwnuBxUgYxsDJRdLng@mail.gmail.com>

Before a change to capabilities and requirements I think this idea of a
running mode is something to consider in general.

As we talk about which modes a runtime handler is going to execute within
we generally seem to be able to talk in terms of named modes - but when it
comes to code within the application server we have some utility methods
e.g. isNormalServer but then in other cases we have more complex boolean
expressions to test the 'mode'.  Sometimes it feels like we could use a
better way for this test.

Regards,
Darran Lofthouse.


On Tue, 12 Dec 2017 at 22:26 David Lloyd <david.lloyd at redhat.com> wrote:

> On Tue, Dec 12, 2017 at 11:15 AM, Brian Stansberry
> <brian.stansberry at redhat.com> wrote:
> > Something the current capabilities/requirements stuff doesn't handle is
> the
> > fact that some capabilities can be configured but won't be turned on in
> some
> > situations (i.e. admin-only). Which means other capabilities that might
> > require them and that are present in admin-only will pass configuration
> > consistency checks but will fail at runtime.
> >
> > I'm not sure what to do about this. Some off the top of my head thoughts:
> >
> > 1) The capability description data on wildly-capabilities includes
> something
> > about this, so people who want to require the capability understand
> whether
> > it can be required.
> >
> > This is easy, and helps avoids future bugs. It's just documentation so it
> > does nothing about the actual server behavior.
> >
> > 2) The registration for capabilities could include "minimal running-mode"
> > data, and then the capability resolution could check that and fail if it
> > finds a mismatch in the current running mode.
>
> I'm inclined towards this option.  But...
>
> > This is more work obviously. It may help surface problems earlier, i.e.
> make
> > it more likely that a testsuite catches a mismatch in time to correct it
> > before a .Final release. It would also have the minor benefit of perhaps
> > providing a better error message for a user who configures a mismatch.
>
> It'd be best if we can detect this more up front if possible.  If this
> kind of mismatch occurs, I think it would never be the user's fault.
>
> --
> - DML
> _______________________________________________
> 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/20171213/02e5d670/attachment-0001.html 

From darran.lofthouse at jboss.com  Wed Dec 13 08:17:20 2017
From: darran.lofthouse at jboss.com (Darran Lofthouse)
Date: Wed, 13 Dec 2017 13:17:20 +0000
Subject: [wildfly-dev] Run level as a factor for capabilities and
	requirements?
In-Reply-To: <CAPhbRDbKDJbH+LgL7emM4we0m2sW-0CEigxjZvzeAmX0OzF_hg@mail.gmail.com>
References: <CAPhbRDbKDJbH+LgL7emM4we0m2sW-0CEigxjZvzeAmX0OzF_hg@mail.gmail.com>
Message-ID: <CAMxVf4MaJExtQJquYq_e=Hw1Gu3Xs70HhGnuQivfhTSJddoraA@mail.gmail.com>

Is this discussion triggered by the recent JDBC realm issue that has been
reported?

The problem in this case is I think it depends on the running mode
requirements of a specific instance of a capability not all capabilities of
that type so the impact becomes transitive.

If we have: -

SecurityDomain -> JDBC Realm -> DataSource

This chain only makes sense in modes where a DataSource can be started.

But we also have: -

SecurityDomain -> PropertiesRealm

This last one makes sense in all modes.

So the overall effect is the minimum running mode of the DataSource affects
the minimum running mode of the SecurityDomain.

Regards,
Darran Lofthouse.


On Tue, 12 Dec 2017 at 19:40 Brian Stansberry <brian.stansberry at redhat.com>
wrote:

> Something the current capabilities/requirements stuff doesn't handle is
> the fact that some capabilities can be configured but won't be turned on in
> some situations (i.e. admin-only). Which means other capabilities that
> might require them and that are present in admin-only will pass
> configuration consistency checks but will fail at runtime.
>
> I'm not sure what to do about this. Some off the top of my head thoughts:
>
> 1) The capability description data on wildly-capabilities includes
> something about this, so people who want to require the capability
> understand whether it can be required.
>
> This is easy, and helps avoids future bugs. It's just documentation so it
> does nothing about the actual server behavior.
>
> 2) The registration for capabilities could include "minimal running-mode"
> data, and then the capability resolution could check that and fail if it
> finds a mismatch in the current running mode.
>
> This is more work obviously. It may help surface problems earlier, i.e.
> make it more likely that a testsuite catches a mismatch in time to correct
> it before a .Final release. It would also have the minor benefit of perhaps
> providing a better error message for a user who configures a mismatch.
>
> 3) The management layer could somehow makes this data available to
> subsystems so they could utilize it. So, the requiror sees the required cap
> is not available in the current run level so it in turn doesn't try and
> install its own cap. Instead logs a WARN or something.
>
> This is the most work, and I have huge doubts about its wisdom. The
> software no longer is reasonably predictable, where something is on or off
> in a given run level; now it's or off depending on whether something else
> is on or off.
>
> For any of these we'll need to formalize our existing concepts into a
> solid run-level concept. I don't think that should be too hard.
>
> [1] https://github.com/wildfly/wildfly-capabilities
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> 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/20171213/d2ea59e4/attachment.html 

From sanne at hibernate.org  Wed Dec 13 12:41:09 2017
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 13 Dec 2017 18:41:09 +0100
Subject: [wildfly-dev] GRPC subsystem proof of concept
In-Reply-To: <CAAoo=c40DL9hKa9RxSaASMozFXZ940W5BDk82ajrWDhB65v0qQ@mail.gmail.com>
References: <CAAoo=c5XKAs5=u5shjA=p-puAqu0+HtS14U+f_KjqVVqH1_urg@mail.gmail.com>
	<CAMxVf4PWkB1JJ97mHRYvrYeT8nFj0EaAYa612BJVNSnzAkVdww@mail.gmail.com>
	<CAF1-sp4372jseCi0vDyV4gVTcvCiqjbDvQ1usUy2EP484qa=GA@mail.gmail.com>
	<CAAoo=c40DL9hKa9RxSaASMozFXZ940W5BDk82ajrWDhB65v0qQ@mail.gmail.com>
Message-ID: <CAFm4XO0gwrRm6+10EiGon674bweXQXbGMiLjBuDcA61C6Xt9Kw@mail.gmail.com>

On 12 December 2017 at 22:24, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
> Not without writing a new protobuf compiler, the compiler does not provide
> any places to hook into the registration process, the only way I could
> manage to do it was to subclass the generated class with a proxy. Protobuf
> generates a fair bit of code for each class anyway, so I don't think the
> proxy will add much percentage wise.

The Google tooling for ProtoBuf expect you to use code generation
depending on the schema, but it's not the only toolset available.

Infinispan also uses ProtoBuf for encoding of client/server data yet
forcing people to use code generation seemed too annoying, so they use
ProtoStream:
 - https://github.com/infinispan/protostream

In turn this is based on Square's Protoparser. I have no idea if it's
more efficient, but it's possible as the alternative feels less
verbose than the codegeneration approach; it's certainly more
convenient.

Hibernate OGM has a "dialect" able to encode JPA storage operations
into Infinispan Remote calls using a combination of the above
libraries; in terms of usage people just deploy JPA annotated pojos on
WildFly and the necessary infrastructure is generated via an internal
metamodel and a chain of method references: no proxies nor code
generation.

Sanne

>
> Stuart
>
> On Wed, Dec 13, 2017 at 1:30 AM, Andrig Miller <anmiller at redhat.com> wrote:
>>
>> Stuart,
>>
>>       Because I have memory footprint on the brain, pretty much all the
>> time now, I wonder if you can change your approach in a way that would
>> lessen MetaSpace usage.  MetaSpace usage is usually the second largest
>> memory hog in Wildfly/EAP, and under certain circumstances it can be larger
>> than heap, when the right JVM settings are used to control heap usage (part
>> of my presentation in 30 minutes).
>>
>> Andy
>>
>> On Tue, Dec 12, 2017 at 3:48 AM, Darran Lofthouse
>> <darran.lofthouse at jboss.com> wrote:
>>>
>>> On the security question, if we are interested in pursuing this we will
>>> get an analysis document started to look at the options we have for
>>> integration with our security implementation.
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>>
>>> On Mon, 11 Dec 2017 at 05:17 Stuart Douglas <stuart.w.douglas at gmail.com>
>>> wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> I have done up a proof of concept of GRPC support in Wildfly, which can
>>>> be found at [1]. GRPC is an RPC protocol designed by Google, that allows for
>>>> easy cross platform invocations.
>>>>
>>>> My proof of concept uses an Undertow based port of GRPC [2] and
>>>> basically works as follows:
>>>>
>>>> - At deployment time Jandex is used to find all non-abstract classes
>>>> that implement io.grpc.BindableService
>>>> - I scan the class hierarchy of these classes to find the protobuf
>>>> generated base class, and create a subclass of this class using
>>>> ProxyFactory, overriding every method except bindService().
>>>> - An instance/proxy is created using the ComponentRegistry to do the
>>>> creation, and the generated proxy delegates all incoming calls to this
>>>> instance
>>>> - At runtime any incoming HTTP/2 requests with a type of
>>>> application/grpc are intercepted, and passed through this newly created
>>>> proxy.
>>>>
>>>> Basically this means that all you need to do as an application developer
>>>> is define your GRPC endpoints using protobuf, implement the classes
>>>> generated by the protobuf compiler and then include them in your
>>>> application, and Wildfly will do the rest. CDI and EJB annotations on your
>>>> GRPC services should work as normal, for example if you put @Stateless on an
>>>> endpoint it should work as expected with a SFSB handling all invocations.
>>>>
>>>> Note that this is a very early stage POC, and lots of stuff is missing
>>>> (most notably security).
>>>>
>>>> Before I go to much further though I though that I should get some
>>>> feedback, e.g.
>>>>
>>>> - Do we actually want this? I am not sure how much interest there is,
>>>> but it seems like GRPC could be very useful in a polyglot microservice
>>>> environment.
>>>> - Is the current implementation the best way of actually registering
>>>> GRPC services, or should we require some kind of defining annotation
>>>> - What security mechanisms should we support? Out of the box standard
>>>> GRPC is fairly limited
>>>> - What do we do about transactions? I am leaning towards not supporting
>>>> them over GRPC, as we already have solutions for Java invocation in the form
>>>> of our EJB protocol, and I think non-Java clients are unlikely to want to
>>>> use this.
>>>>
>>>> Stuart
>>>>
>>>> [1] https://github.com/stuartwdouglas/wildfly/tree/grpc
>>>> [2] https://github.com/stuartwdouglas/undertow-grpc
>>>> _______________________________________________
>>>> 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
>>
>>
>>
>>
>> --
>> Andrig (Andy) T. Miller
>> Global Platform Director, Middleware
>> Red Hat, Inc.
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From mazz at redhat.com  Wed Dec 13 17:19:38 2017
From: mazz at redhat.com (John Mazzitelli)
Date: Wed, 13 Dec 2017 17:19:38 -0500 (EST)
Subject: [wildfly-dev] some JMX APIs cannot obtain an MBean that exists
In-Reply-To: <196822192.54390328.1513202385132.JavaMail.zimbra@redhat.com>
Message-ID: <1472834285.54412596.1513203578265.JavaMail.zimbra@redhat.com>

I'm seeing odd behavior with the JMX API implementation in Wildfly 11.

If you grab this Makefile and two .java files I use for testing you can see it yourself - just put these in a tmp directory somewhere:

wget https://raw.githubusercontent.com/jmazzitelli/test/master/javaagent/Makefile
wget https://raw.githubusercontent.com/jmazzitelli/test/master/javaagent/TestJavaAgent.java
wget https://raw.githubusercontent.com/jmazzitelli/test/master/javaagent/TestJavaAgentMXBean.java

Then just run "make download-wildfly unzip-wildfly compile run" (make sure you don't have other WildFly servers running to avoid port conflicts)

This runs WF 11 with a -javaagent attached. In the server output, you will see this:

16:31:05,290 INFO  [stdout] (Test Java Agent Thread) =============================================================
16:31:05,291 INFO  [stdout] (Test Java Agent Thread) FIND INFORMATION ABOUT MBEAN: jboss.as:management-root=server
16:31:05,291 INFO  [stdout] (Test Java Agent Thread) =============================================================
16:31:05,291 INFO  [stdout] (Test Java Agent Thread) isRegistered:
16:31:05,291 INFO  [stdout] (Test Java Agent Thread) true
16:31:05,291 INFO  [stdout] (Test Java Agent Thread) getMBeanInfo:
16:31:05,291 INFO  [stdout] (Test Java Agent Thread)   description: The root node of the server-level management model.
16:31:05,291 INFO  [stdout] (Test Java Agent Thread)   #attributes: 19
16:31:05,291 INFO  [stdout] (Test Java Agent Thread) getAttribute:
16:31:05,291 INFO  [stdout] (Test Java Agent Thread) serverState=reload-required
16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryNames:
16:31:05,291 INFO  [stdout] (Test Java Agent Thread) []
16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryMBeans:
16:31:05,291 INFO  [stdout] (Test Java Agent Thread) []
16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryNames(null, null):
16:31:05,291 INFO  [stdout] (Test Java Agent Thread) FOUND IT: jboss.as:management-root=server
16:31:05,291 INFO  [stdout] (Test Java Agent Thread) =============================================================

You will see SOME JMX APIs can see the MBean "jboss.as:management-root=server",
but queryMBeans and queryNames canNOT (note the empty arrays []).

But notice getMBeanInfo CAN see it - I can even get the serverState attribute value from that (you can see it is in reload-required state - I see the same behavior even if it was in "running" state).

But again, queryMBeans returns nothing.

Oddly, queryNames(null, null) DOES return it in the list (see the "FOUND IT" line). It is only if I specifically ask for it does it fail in the query API.

Finally, note that it seems this MBean "jboss.as:management-root=server" is special - because it is specifically broke - if i switch to querying for "jboss.as:subsystem=transactions" it all works fine, even the query APIs:

17:16:39,541 INFO  [stdout] (Test Java Agent Thread) queryNames:
17:16:39,541 INFO  [stdout] (Test Java Agent Thread) [jboss.as:subsystem=transactions]
17:16:39,541 INFO  [stdout] (Test Java Agent Thread) queryMBeans:
17:16:39,541 INFO  [stdout] (Test Java Agent Thread) [org.jboss.as.controller.ModelController[jboss.as:subsystem=transactions]]

This problem was seen by others as well (with the same MBean I'm trying to get) - see:

https://github.com/prometheus/jmx_exporter/issues/89

The person there claims queryNames is broke but queryMBeans is OK - that does not work in my example either. Neither query API works.

I searched JIRA, found nothing related to this MBean not being queryable.

From jason.greene at redhat.com  Wed Dec 13 21:51:57 2017
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 13 Dec 2017 20:51:57 -0600
Subject: [wildfly-dev] WildFly 12 Plans, EE8,
	and Move to Quarterly Iterative Releases
Message-ID: <1C2615A5-9731-47EB-8FC2-FFBB4BA2C5FE@redhat.com>


Hello Everyone,

Release Model Changes
????????????????????-
In order to bring new capabilities to the community quicker, we plan to move to a more iterative time-boxed approach, starting with WildFly 12 (and continuing with 13, 14, etc). By time-boxed, I mean the each release aims to have a fixed and reliable delivery window that approximates a calendar quarter. Since these time-frames are fixed, it?s important that any given feature or improvement not hold up a release. To facilitate this we need to make major changes to our development process. Currently development for any enhancement is merged in chunks, as it progresses from inception to completion. This means to have something worthy of release, we must either block for its completion or roll it back. The latter is often difficult, since at any given moment there are many features under active development, and their respective implementations can become co-dependent. Additionally, its common for component dependencies to start off as Alphas and/or Betas, and we end up needing to wait for those components to hit Final before we can cut the release. 

The solution to this problem is to rely more on topic branches, and only merge fully completed work to master. By fully complete, I mean all PRs on master should be fully developed, tested, and documented[1]. Additionally any updated dependencies must only be against Final/GA components.

This has a number of advantages:

A. Master becomes always stable, always releasable. So at any given moment we can decided to cut a release[1]
B. Nightly builds become way more usable, and a great feedback channel (a release starts to have less importance)
C. If a feature takes longer than expected, no big deal, it will be picked up in the next cycle[2]
D. Should anything cause a major regression, not caught in testing it will be easier to revert, since the history will be cleaner

Since in-progress work will need to be based on topic branches, custom jobs on ci.wildfly.org will need to be relied upon instead of the automated CI that happens when you submit a PR (although that?s still important and still staying). Additionally if two changes/improvements are interrelated, then they will need to either share a topic branch, or find a way to construct the work independently (potentially adding and removing a temporary construct until both are merged).


[1] To make it easier to associate documentation with the PR, we are looking to move to an asciidoc based solution instead of confluence like we utilize today.

[2] While this is generally the case, there are some activities we can?t avoid before releasing, such as ensuring a TCK run has completed. 

[3] An important aspect of C is that iterations have a short enough cycle, such that the pressure to make a particular iteration is low enough to avoid the urge to try and cram something in, and potentially compromise quality (e.g. no docs etc).


Java EE8
????????
As part of adopting this model, we aim to deliver Java EE8 in incremental chunks. Adding support for specs individually in batches. As an example for WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to unfortunate restrictions in EE certification, we will need to have a separate configuration profile or property to enable these additional APIs until we complete full EE8 certification.

Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
????????????????????????
+ Adopt new release model
+ Java 9 improvements
+ Servlet 4
+ JSON-B (incorporating Yasoon)
+ CDI 2
+ JSF 2.3
+ Metaspace usage improvements
+ early/initial changes to accommodate the new provisioning effort (easy slimming, updates, etc)
 
Proposed WildFly 13 Goals (Very Tentative) [May 2018]
???????????????????????????-
+ New EE Security Spec
+ Adoption of provisioning 
+ JPA 2.2
+ JAX-RS 2.1
+ BV 2.0
+ Agroal inclusion 

Just to highlight that with this new model, that these goals I am proposing are not something we would block on, any given item might be deferred to the next release if it?s not quite ready. Let me know if you have any additional major items you are planning to contribute towards 12.

Thanks!

-Jason







From jason.greene at redhat.com  Wed Dec 13 21:51:57 2017
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 13 Dec 2017 20:51:57 -0600
Subject: [wildfly-dev] WildFly 12 Plans, EE8,
	and Move to Quarterly Iterative Releases
Message-ID: <B04000C1-C679-4DAB-BBC5-8AAE2B2DC580@redhat.com>


Hello Everyone,

Release Model Changes
????????????????????-
In order to bring new capabilities to the community quicker, we plan to move to a more iterative time-boxed approach, starting with WildFly 12 (and continuing with 13, 14, etc). By time-boxed, I mean the each release aims to have a fixed and reliable delivery window that approximates a calendar quarter. Since these time-frames are fixed, it?s important that any given feature or improvement not hold up a release. To facilitate this we need to make major changes to our development process. Currently development for any enhancement is merged in chunks, as it progresses from inception to completion. This means to have something worthy of release, we must either block for its completion or roll it back. The latter is often difficult, since at any given moment there are many features under active development, and their respective implementations can become co-dependent. Additionally, its common for component dependencies to start off as Alphas and/or Betas, and we end up needing to wait for those components to hit Final before we can cut the release. 

The solution to this problem is to rely more on topic branches, and only merge fully completed work to master. By fully complete, I mean all PRs on master should be fully developed, tested, and documented[1]. Additionally any updated dependencies must only be against Final/GA components.

This has a number of advantages:

A. Master becomes always stable, always releasable. So at any given moment we can decided to cut a release[1]
B. Nightly builds become way more usable, and a great feedback channel (a release starts to have less importance)
C. If a feature takes longer than expected, no big deal, it will be picked up in the next cycle[2]
D. Should anything cause a major regression, not caught in testing it will be easier to revert, since the history will be cleaner

Since in-progress work will need to be based on topic branches, custom jobs on ci.wildfly.org will need to be relied upon instead of the automated CI that happens when you submit a PR (although that?s still important and still staying). Additionally if two changes/improvements are interrelated, then they will need to either share a topic branch, or find a way to construct the work independently (potentially adding and removing a temporary construct until both are merged).


[1] To make it easier to associate documentation with the PR, we are looking to move to an asciidoc based solution instead of confluence like we utilize today.

[2] While this is generally the case, there are some activities we can?t avoid before releasing, such as ensuring a TCK run has completed. 

[3] An important aspect of C is that iterations have a short enough cycle, such that the pressure to make a particular iteration is low enough to avoid the urge to try and cram something in, and potentially compromise quality (e.g. no docs etc).


Java EE8
????????
As part of adopting this model, we aim to deliver Java EE8 in incremental chunks. Adding support for specs individually in batches. As an example for WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to unfortunate restrictions in EE certification, we will need to have a separate configuration profile or property to enable these additional APIs until we complete full EE8 certification.

Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
????????????????????????
+ Adopt new release model
+ Java 9 improvements
+ Servlet 4
+ JSON-B (incorporating Yasoon)
+ CDI 2
+ JSF 2.3
+ Metaspace usage improvements
+ early/initial changes to accommodate the new provisioning effort (easy slimming, updates, etc)
 
Proposed WildFly 13 Goals (Very Tentative) [May 2018]
???????????????????????????-
+ New EE Security Spec
+ Adoption of provisioning 
+ JPA 2.2
+ JAX-RS 2.1
+ BV 2.0
+ Agroal inclusion 

Just to highlight that with this new model, that these goals I am proposing are not something we would block on, any given item might be deferred to the next release if it?s not quite ready. Let me know if you have any additional major items you are planning to contribute towards 12.

Thanks!

-Jason







From jason.greene at redhat.com  Wed Dec 13 22:00:55 2017
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 13 Dec 2017 21:00:55 -0600
Subject: [wildfly-dev] test - please ignore - test
Message-ID: <626BB1E4-B1BA-4FC2-A420-5A7BCF1B5761@redhat.com>

$SUBJECT

From jason.greene at redhat.com  Wed Dec 13 22:06:21 2017
From: jason.greene at redhat.com (Jason Greene)
Date: Wed, 13 Dec 2017 21:06:21 -0600
Subject: [wildfly-dev] WildFly 12 Plans, EE8,
	and Move to Quarterly Iterative Releases
Message-ID: <B2B3EBD1-7BCC-4483-BFC2-F36AE0C10C70@redhat.com>

Hello Everyone,

Release Model Changes
????????????????????-
In order to bring new capabilities to the community quicker, we plan to move to a more iterative time-boxed approach, starting with WildFly 12 (and continuing with 13, 14, etc). By time-boxed, I mean the each release aims to have a fixed and reliable delivery window that approximates a calendar quarter. Since these time-frames are fixed, it?s important that any given feature or improvement not hold up a release. To facilitate this we need to make major changes to our development process. Currently development for any enhancement is merged in chunks, as it progresses from inception to completion. This means to have something worthy of release, we must either block for its completion or roll it back. The latter is often difficult, since at any given moment there are many features under active development, and their respective implementations can become co-dependent. Additionally, its common for component dependencies to start off as Alphas and/or Betas, and we end up needing to wait for those components to hit Final before we can cut the release. 

The solution to this problem is to rely more on topic branches, and only merge fully completed work to master. By fully complete, I mean all PRs on master should be fully developed, tested, and documented[1]. Additionally any updated dependencies must only be against Final/GA components.

This has a number of advantages:

A. Master becomes always stable, always releasable. So at any given moment we can decided to cut a release[1]
B. Nightly builds become way more usable, and a great feedback channel (a release starts to have less importance)
C. If a feature takes longer than expected, no big deal, it will be picked up in the next cycle[2]
D. Should anything cause a major regression, not caught in testing it will be easier to revert, since the history will be cleaner

Since in-progress work will need to be based on topic branches, custom jobs on ci.wildfly.org will need to be relied upon instead of the automated CI that happens when you submit a PR (although that?s still important and still staying). Additionally if two changes/improvements are interrelated, then they will need to either share a topic branch, or find a way to construct the work independently (potentially adding and removing a temporary construct until both are merged).


[1] To make it easier to associate documentation with the PR, we are looking to move to an asciidoc based solution instead of confluence like we utilize today.

[2] While this is generally the case, there are some activities we can?t avoid before releasing, such as ensuring a TCK run has completed. 

[3] An important aspect of C is that iterations have a short enough cycle, such that the pressure to make a particular iteration is low enough to avoid the urge to try and cram something in, and potentially compromise quality (e.g. no docs etc).


Java EE8
????????
As part of adopting this model, we aim to deliver Java EE8 in incremental chunks. Adding support for specs individually in batches. As an example for WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to unfortunate restrictions in EE certification, we will need to have a separate configuration profile or property to enable these additional APIs until we complete full EE8 certification.

Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
????????????????????????
+ Adopt new release model
+ Java 9 improvements
+ Servlet 4
+ JSON-B (incorporating Yasoon)
+ CDI 2
+ JSF 2.3
+ Metaspace usage improvements
+ early/initial changes to accommodate the new provisioning effort (easy slimming, updates, etc)

Proposed WildFly 13 Goals (Very Tentative) [May 2018]
???????????????????????????-
+ New EE Security Spec
+ Adoption of provisioning 
+ JPA 2.2
+ JAX-RS 2.1
+ BV 2.0
+ Agroal inclusion 

Just to highlight that with this new model, that these goals I am proposing are not something we would block on, any given item might be deferred to the next release if it?s not quite ready. Let me know if you have any additional major items you are planning to contribute towards 12.

Thanks!

-Jason







From jai.forums2013 at gmail.com  Thu Dec 14 00:32:22 2017
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 14 Dec 2017 11:02:22 +0530
Subject: [wildfly-dev] WildFly 12 Plans, EE8,
 and Move to Quarterly Iterative Releases
In-Reply-To: <1C2615A5-9731-47EB-8FC2-FFBB4BA2C5FE@redhat.com>
References: <1C2615A5-9731-47EB-8FC2-FFBB4BA2C5FE@redhat.com>
Message-ID: <8d12f567-f6b2-6504-bd11-dd2398ef659b@gmail.com>

Hi Jason,

Looks good in terms of quicker releases.

A related question, given this proposal, would it mean there will never 
be Alpha, Beta, CR of WildFly releases anymore? Furthermore, every 
release starting WildFly 12 will now be a major release (in terms of 
version numbers and even feature/changes)? What I mean is, once WildFly 
12 is released, there won't be any more releases of 12.x (for example, 
12.1.0 etc...)?

P.S: Unrelated - is there any issue with mail delivery to this list. I 
received this mail just a few minutes back while the mail actually seems 
to have been sent a couple of hours back?

-Jaikiran


On 14/12/17 8:21 AM, Jason Greene wrote:
> Hello Everyone,
>
> Release Model Changes
> ????????????????????-
> In order to bring new capabilities to the community quicker, we plan to move to a more iterative time-boxed approach, starting with WildFly 12 (and continuing with 13, 14, etc). By time-boxed, I mean the each release aims to have a fixed and reliable delivery window that approximates a calendar quarter. Since these time-frames are fixed, it?s important that any given feature or improvement not hold up a release. To facilitate this we need to make major changes to our development process. Currently development for any enhancement is merged in chunks, as it progresses from inception to completion. This means to have something worthy of release, we must either block for its completion or roll it back. The latter is often difficult, since at any given moment there are many features under active development, and their respective implementations can become co-dependent. Additionally, its common for component dependencies to start off as Alphas and/or Betas, and we end up needing to wait for those components to hit Final before we can cut the release.
>
> The solution to this problem is to rely more on topic branches, and only merge fully completed work to master. By fully complete, I mean all PRs on master should be fully developed, tested, and documented[1]. Additionally any updated dependencies must only be against Final/GA components.
>
> This has a number of advantages:
>
> A. Master becomes always stable, always releasable. So at any given moment we can decided to cut a release[1]
> B. Nightly builds become way more usable, and a great feedback channel (a release starts to have less importance)
> C. If a feature takes longer than expected, no big deal, it will be picked up in the next cycle[2]
> D. Should anything cause a major regression, not caught in testing it will be easier to revert, since the history will be cleaner
>
> Since in-progress work will need to be based on topic branches, custom jobs on ci.wildfly.org will need to be relied upon instead of the automated CI that happens when you submit a PR (although that?s still important and still staying). Additionally if two changes/improvements are interrelated, then they will need to either share a topic branch, or find a way to construct the work independently (potentially adding and removing a temporary construct until both are merged).
>
>
> [1] To make it easier to associate documentation with the PR, we are looking to move to an asciidoc based solution instead of confluence like we utilize today.
>
> [2] While this is generally the case, there are some activities we can?t avoid before releasing, such as ensuring a TCK run has completed.
>
> [3] An important aspect of C is that iterations have a short enough cycle, such that the pressure to make a particular iteration is low enough to avoid the urge to try and cram something in, and potentially compromise quality (e.g. no docs etc).
>
>
> Java EE8
> ????????
> As part of adopting this model, we aim to deliver Java EE8 in incremental chunks. Adding support for specs individually in batches. As an example for WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to unfortunate restrictions in EE certification, we will need to have a separate configuration profile or property to enable these additional APIs until we complete full EE8 certification.
>
> Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
> ????????????????????????
> + Adopt new release model
> + Java 9 improvements
> + Servlet 4
> + JSON-B (incorporating Yasoon)
> + CDI 2
> + JSF 2.3
> + Metaspace usage improvements
> + early/initial changes to accommodate the new provisioning effort (easy slimming, updates, etc)
>   
> Proposed WildFly 13 Goals (Very Tentative) [May 2018]
> ???????????????????????????-
> + New EE Security Spec
> + Adoption of provisioning
> + JPA 2.2
> + JAX-RS 2.1
> + BV 2.0
> + Agroal inclusion
>
> Just to highlight that with this new model, that these goals I am proposing are not something we would block on, any given item might be deferred to the next release if it?s not quite ready. Let me know if you have any additional major items you are planning to contribute towards 12.
>
> Thanks!
>
> -Jason
>
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev




From rsvoboda at redhat.com  Thu Dec 14 04:59:52 2017
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Thu, 14 Dec 2017 04:59:52 -0500 (EST)
Subject: [wildfly-dev] WildFly 12 Plans, EE8,
 and Move to Quarterly Iterative Releases
In-Reply-To: <B2B3EBD1-7BCC-4483-BFC2-F36AE0C10C70@redhat.com>
References: <B2B3EBD1-7BCC-4483-BFC2-F36AE0C10C70@redhat.com>
Message-ID: <185438644.54648708.1513245592026.JavaMail.zimbra@redhat.com>


> + Agroal inclusion
What's that ^^^ ? 

Thank you.
Rostislav

----- Original Message -----
> Hello Everyone,
> 
> Release Model Changes
> ????????????????????-
> In order to bring new capabilities to the community quicker, we plan to move
> to a more iterative time-boxed approach, starting with WildFly 12 (and
> continuing with 13, 14, etc). By time-boxed, I mean the each release aims to
> have a fixed and reliable delivery window that approximates a calendar
> quarter. Since these time-frames are fixed, it?s important that any given
> feature or improvement not hold up a release. To facilitate this we need to
> make major changes to our development process. Currently development for any
> enhancement is merged in chunks, as it progresses from inception to
> completion. This means to have something worthy of release, we must either
> block for its completion or roll it back. The latter is often difficult,
> since at any given moment there are many features under active development,
> and their respective implementations can become co-dependent. Additionally,
> its common for component dependencies to start off as Alphas and/or Betas,
> and we end up needing to wait for those components to hit Final before we
> can cut the release.
> 
> The solution to this problem is to rely more on topic branches, and only
> merge fully completed work to master. By fully complete, I mean all PRs on
> master should be fully developed, tested, and documented[1]. Additionally
> any updated dependencies must only be against Final/GA components.
> 
> This has a number of advantages:
> 
> A. Master becomes always stable, always releasable. So at any given moment we
> can decided to cut a release[1]
> B. Nightly builds become way more usable, and a great feedback channel (a
> release starts to have less importance)
> C. If a feature takes longer than expected, no big deal, it will be picked up
> in the next cycle[2]
> D. Should anything cause a major regression, not caught in testing it will be
> easier to revert, since the history will be cleaner
> 
> Since in-progress work will need to be based on topic branches, custom jobs
> on ci.wildfly.org will need to be relied upon instead of the automated CI
> that happens when you submit a PR (although that?s still important and still
> staying). Additionally if two changes/improvements are interrelated, then
> they will need to either share a topic branch, or find a way to construct
> the work independently (potentially adding and removing a temporary
> construct until both are merged).
> 
> 
> [1] To make it easier to associate documentation with the PR, we are looking
> to move to an asciidoc based solution instead of confluence like we utilize
> today.
> 
> [2] While this is generally the case, there are some activities we can?t
> avoid before releasing, such as ensuring a TCK run has completed.
> 
> [3] An important aspect of C is that iterations have a short enough cycle,
> such that the pressure to make a particular iteration is low enough to avoid
> the urge to try and cram something in, and potentially compromise quality
> (e.g. no docs etc).
> 
> 
> Java EE8
> ????????
> As part of adopting this model, we aim to deliver Java EE8 in incremental
> chunks. Adding support for specs individually in batches. As an example for
> WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to
> unfortunate restrictions in EE certification, we will need to have a
> separate configuration profile or property to enable these additional APIs
> until we complete full EE8 certification.
> 
> Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
> ????????????????????????
> + Adopt new release model
> + Java 9 improvements
> + Servlet 4
> + JSON-B (incorporating Yasoon)
> + CDI 2
> + JSF 2.3
> + Metaspace usage improvements
> + early/initial changes to accommodate the new provisioning effort (easy
> slimming, updates, etc)
> 
> Proposed WildFly 13 Goals (Very Tentative) [May 2018]
> ???????????????????????????-
> + New EE Security Spec
> + Adoption of provisioning
> + JPA 2.2
> + JAX-RS 2.1
> + BV 2.0
> + Agroal inclusion
> 
> Just to highlight that with this new model, that these goals I am proposing
> are not something we would block on, any given item might be deferred to the
> next release if it?s not quite ready. Let me know if you have any additional
> major items you are planning to contribute towards 12.
> 
> Thanks!
> 
> -Jason
> 
> 
> 
> 
> 
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From kkhan at redhat.com  Thu Dec 14 05:34:35 2017
From: kkhan at redhat.com (Kabir Khan)
Date: Thu, 14 Dec 2017 10:34:35 +0000
Subject: [wildfly-dev] some JMX APIs cannot obtain an MBean that exists
In-Reply-To: <1472834285.54412596.1513203578265.JavaMail.zimbra@redhat.com>
References: <1472834285.54412596.1513203578265.JavaMail.zimbra@redhat.com>
Message-ID: <4AB28760-C9C3-4BCC-8A27-B709EAE46C6C@redhat.com>

I have not tried your example, but I have an educated guess for what is going on.

We use org.jboss.as.jmx.PluggableMBeanServerBuilder as an implementation for javax.management.MBeanServerBuilder which is what creates the platform mbean server. The resulting org.jboss.as.jmx.PluggableMBeanServerImpl is what allows the JMX subsystem to expose the management api via jmx. 

This gets set almost immediately in the boot process in the block at https://github.com/jboss-modules/jboss-modules/blob/1.x/src/main/java/org/jboss/modules/Main.java#L520.

I would guess that your javaagent ends up calling getPlatformMBeanServer() before JBoss Modules has had a chance to do its stuff, and as the platform mbean server gets set on the first call to it, you end up with the default implementation of it. This will break things for other users wanting to use the pluggable mbean server too :)

Some fixes that come to mind:
- wait until we've had a chance to initialise before calling getPlatformMBeanServer() from your agent
- make sure that the jmx module is on your javaagent's classpath and replicate what JBoss Modules does before calling getPlatformMBeanServer. For the server org.jboss.as.standalone is used as the boot module, this in turn pulls in the org.jboss.as.jmx module, which has the META-INF/services/org.jboss.as.jmx.PluggableMBeanServerBuilder file to load the proper implementation

Thanks,

Kabir



> On 13 Dec 2017, at 22:19, John Mazzitelli <mazz at redhat.com> wrote:
> 
> I'm seeing odd behavior with the JMX API implementation in Wildfly 11.
> 
> If you grab this Makefile and two .java files I use for testing you can see it yourself - just put these in a tmp directory somewhere:
> 
> wget https://raw.githubusercontent.com/jmazzitelli/test/master/javaagent/Makefile
> wget https://raw.githubusercontent.com/jmazzitelli/test/master/javaagent/TestJavaAgent.java
> wget https://raw.githubusercontent.com/jmazzitelli/test/master/javaagent/TestJavaAgentMXBean.java
> 
> Then just run "make download-wildfly unzip-wildfly compile run" (make sure you don't have other WildFly servers running to avoid port conflicts)
> 
> This runs WF 11 with a -javaagent attached. In the server output, you will see this:
> 
> 16:31:05,290 INFO  [stdout] (Test Java Agent Thread) =============================================================
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) FIND INFORMATION ABOUT MBEAN: jboss.as:management-root=server
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) =============================================================
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) isRegistered:
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) true
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) getMBeanInfo:
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)   description: The root node of the server-level management model.
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)   #attributes: 19
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) getAttribute:
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) serverState=reload-required
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryNames:
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) []
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryMBeans:
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) []
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryNames(null, null):
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) FOUND IT: jboss.as:management-root=server
> 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) =============================================================
> 
> You will see SOME JMX APIs can see the MBean "jboss.as:management-root=server",
> but queryMBeans and queryNames canNOT (note the empty arrays []).
> 
> But notice getMBeanInfo CAN see it - I can even get the serverState attribute value from that (you can see it is in reload-required state - I see the same behavior even if it was in "running" state).
> 
> But again, queryMBeans returns nothing.
> 
> Oddly, queryNames(null, null) DOES return it in the list (see the "FOUND IT" line). It is only if I specifically ask for it does it fail in the query API.
> 
> Finally, note that it seems this MBean "jboss.as:management-root=server" is special - because it is specifically broke - if i switch to querying for "jboss.as:subsystem=transactions" it all works fine, even the query APIs:
> 
> 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) queryNames:
> 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) [jboss.as:subsystem=transactions]
> 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) queryMBeans:
> 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) [org.jboss.as.controller.ModelController[jboss.as:subsystem=transactions]]
> 
> This problem was seen by others as well (with the same MBean I'm trying to get) - see:
> 
> https://github.com/prometheus/jmx_exporter/issues/89
> 
> The person there claims queryNames is broke but queryMBeans is OK - that does not work in my example either. Neither query API works.
> 
> I searched JIRA, found nothing related to this MBean not being queryable.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From steve at hibernate.org  Thu Dec 14 07:01:04 2017
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 14 Dec 2017 12:01:04 +0000
Subject: [wildfly-dev] WildFly 12 Plans, EE8,
 and Move to Quarterly Iterative Releases
In-Reply-To: <185438644.54648708.1513245592026.JavaMail.zimbra@redhat.com>
References: <B2B3EBD1-7BCC-4483-BFC2-F36AE0C10C70@redhat.com>
	<185438644.54648708.1513245592026.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9ufxHG4qxri7b_3-Df6-pfuBfW2ej9rhr43offVWkmrfg@mail.gmail.com>

Its a high-performance connection pool written by Luis from the performance
team.

On Thu, Dec 14, 2017 at 4:12 AM Rostislav Svoboda <rsvoboda at redhat.com>
wrote:

>
> > + Agroal inclusion
> What's that ^^^ ?
>
> Thank you.
> Rostislav
>
> ----- Original Message -----
> > Hello Everyone,
> >
> > Release Model Changes
> > ????????????????????-
> > In order to bring new capabilities to the community quicker, we plan to
> move
> > to a more iterative time-boxed approach, starting with WildFly 12 (and
> > continuing with 13, 14, etc). By time-boxed, I mean the each release
> aims to
> > have a fixed and reliable delivery window that approximates a calendar
> > quarter. Since these time-frames are fixed, it?s important that any given
> > feature or improvement not hold up a release. To facilitate this we need
> to
> > make major changes to our development process. Currently development for
> any
> > enhancement is merged in chunks, as it progresses from inception to
> > completion. This means to have something worthy of release, we must
> either
> > block for its completion or roll it back. The latter is often difficult,
> > since at any given moment there are many features under active
> development,
> > and their respective implementations can become co-dependent.
> Additionally,
> > its common for component dependencies to start off as Alphas and/or
> Betas,
> > and we end up needing to wait for those components to hit Final before we
> > can cut the release.
> >
> > The solution to this problem is to rely more on topic branches, and only
> > merge fully completed work to master. By fully complete, I mean all PRs
> on
> > master should be fully developed, tested, and documented[1]. Additionally
> > any updated dependencies must only be against Final/GA components.
> >
> > This has a number of advantages:
> >
> > A. Master becomes always stable, always releasable. So at any given
> moment we
> > can decided to cut a release[1]
> > B. Nightly builds become way more usable, and a great feedback channel (a
> > release starts to have less importance)
> > C. If a feature takes longer than expected, no big deal, it will be
> picked up
> > in the next cycle[2]
> > D. Should anything cause a major regression, not caught in testing it
> will be
> > easier to revert, since the history will be cleaner
> >
> > Since in-progress work will need to be based on topic branches, custom
> jobs
> > on ci.wildfly.org will need to be relied upon instead of the automated
> CI
> > that happens when you submit a PR (although that?s still important and
> still
> > staying). Additionally if two changes/improvements are interrelated, then
> > they will need to either share a topic branch, or find a way to construct
> > the work independently (potentially adding and removing a temporary
> > construct until both are merged).
> >
> >
> > [1] To make it easier to associate documentation with the PR, we are
> looking
> > to move to an asciidoc based solution instead of confluence like we
> utilize
> > today.
> >
> > [2] While this is generally the case, there are some activities we can?t
> > avoid before releasing, such as ensuring a TCK run has completed.
> >
> > [3] An important aspect of C is that iterations have a short enough
> cycle,
> > such that the pressure to make a particular iteration is low enough to
> avoid
> > the urge to try and cram something in, and potentially compromise quality
> > (e.g. no docs etc).
> >
> >
> > Java EE8
> > ????????
> > As part of adopting this model, we aim to deliver Java EE8 in incremental
> > chunks. Adding support for specs individually in batches. As an example
> for
> > WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to
> > unfortunate restrictions in EE certification, we will need to have a
> > separate configuration profile or property to enable these additional
> APIs
> > until we complete full EE8 certification.
> >
> > Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
> > ????????????????????????
> > + Adopt new release model
> > + Java 9 improvements
> > + Servlet 4
> > + JSON-B (incorporating Yasoon)
> > + CDI 2
> > + JSF 2.3
> > + Metaspace usage improvements
> > + early/initial changes to accommodate the new provisioning effort (easy
> > slimming, updates, etc)
> >
> > Proposed WildFly 13 Goals (Very Tentative) [May 2018]
> > ???????????????????????????-
> > + New EE Security Spec
> > + Adoption of provisioning
> > + JPA 2.2
> > + JAX-RS 2.1
> > + BV 2.0
> > + Agroal inclusion
> >
> > Just to highlight that with this new model, that these goals I am
> proposing
> > are not something we would block on, any given item might be deferred to
> the
> > next release if it?s not quite ready. Let me know if you have any
> additional
> > major items you are planning to contribute towards 12.
> >
> > Thanks!
> >
> > -Jason
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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/20171214/c8f8b79f/attachment.html 

From gunnar at hibernate.org  Thu Dec 14 08:15:24 2017
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 14 Dec 2017 14:15:24 +0100
Subject: [wildfly-dev] WildFly 12 Plans, EE8,
 and Move to Quarterly Iterative Releases
In-Reply-To: <1C2615A5-9731-47EB-8FC2-FFBB4BA2C5FE@redhat.com>
References: <1C2615A5-9731-47EB-8FC2-FFBB4BA2C5FE@redhat.com>
Message-ID: <CADGJaX9iy4HYihAf=mo+MzQMHnFC7RxvGc8QCveziswAZ_MCKw@mail.gmail.com>

Hi Jason,

+1 for the plan to do time-boxed releases with a three month cadence.

Maybe you could break down the schedule of a given release iteration a bit
further, so e.g. if WF 12 is scheduled for February 28th, what are the mile
stone dates for delivering PRs with new developments in WF itself,
component upgrades, bugfixes etc.? Having a schedule like for instance
OpenJDK has [1] would be helpful, so everyone knows what needs to be done
by when.

Speaking about BV 2.0 and HV 6, we're ready to deliver this (in last week's
Hibernate team meeting we agreed on sending a PR for updating WF this
week). We've done a couple of 6.0.x releases (at 6.0.6 atm.), i.e. it has
been honed nicely and also performance has been improved significantly [2].
So I'd hope we can included this in 12 already?

Thanks,

--Gunnar

[1] http://openjdk.java.net/projects/jdk/10/
[2] http://in.relation.to/2017/10/31/bean-validation-benchmark-revisited/

2017-12-14 3:51 GMT+01:00 Jason Greene <jason.greene at redhat.com>:

>
> Hello Everyone,
>
> Release Model Changes
> ????????????????????-
> In order to bring new capabilities to the community quicker, we plan to
> move to a more iterative time-boxed approach, starting with WildFly 12 (and
> continuing with 13, 14, etc). By time-boxed, I mean the each release aims
> to have a fixed and reliable delivery window that approximates a calendar
> quarter. Since these time-frames are fixed, it?s important that any given
> feature or improvement not hold up a release. To facilitate this we need to
> make major changes to our development process. Currently development for
> any enhancement is merged in chunks, as it progresses from inception to
> completion. This means to have something worthy of release, we must either
> block for its completion or roll it back. The latter is often difficult,
> since at any given moment there are many features under active development,
> and their respective implementations can become co-dependent. Additionally,
> its common for component dependencies to start off as Alphas and/or Betas,
> and we end up needing to wait for those components to hit Final before we
> can cut the release.
>
> The solution to this problem is to rely more on topic branches, and only
> merge fully completed work to master. By fully complete, I mean all PRs on
> master should be fully developed, tested, and documented[1]. Additionally
> any updated dependencies must only be against Final/GA components.
>
> This has a number of advantages:
>
> A. Master becomes always stable, always releasable. So at any given moment
> we can decided to cut a release[1]
> B. Nightly builds become way more usable, and a great feedback channel (a
> release starts to have less importance)
> C. If a feature takes longer than expected, no big deal, it will be picked
> up in the next cycle[2]
> D. Should anything cause a major regression, not caught in testing it will
> be easier to revert, since the history will be cleaner
>
> Since in-progress work will need to be based on topic branches, custom
> jobs on ci.wildfly.org will need to be relied upon instead of the
> automated CI that happens when you submit a PR (although that?s still
> important and still staying). Additionally if two changes/improvements are
> interrelated, then they will need to either share a topic branch, or find a
> way to construct the work independently (potentially adding and removing a
> temporary construct until both are merged).
>
>
> [1] To make it easier to associate documentation with the PR, we are
> looking to move to an asciidoc based solution instead of confluence like we
> utilize today.
>
> [2] While this is generally the case, there are some activities we can?t
> avoid before releasing, such as ensuring a TCK run has completed.
>
> [3] An important aspect of C is that iterations have a short enough cycle,
> such that the pressure to make a particular iteration is low enough to
> avoid the urge to try and cram something in, and potentially compromise
> quality (e.g. no docs etc).
>
>
> Java EE8
> ????????
> As part of adopting this model, we aim to deliver Java EE8 in incremental
> chunks. Adding support for specs individually in batches. As an example for
> WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to
> unfortunate restrictions in EE certification, we will need to have a
> separate configuration profile or property to enable these additional APIs
> until we complete full EE8 certification.
>
> Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
> ????????????????????????
> + Adopt new release model
> + Java 9 improvements
> + Servlet 4
> + JSON-B (incorporating Yasoon)
> + CDI 2
> + JSF 2.3
> + Metaspace usage improvements
> + early/initial changes to accommodate the new provisioning effort (easy
> slimming, updates, etc)
>
> Proposed WildFly 13 Goals (Very Tentative) [May 2018]
> ???????????????????????????-
> + New EE Security Spec
> + Adoption of provisioning
> + JPA 2.2
> + JAX-RS 2.1
> + BV 2.0
> + Agroal inclusion
>
> Just to highlight that with this new model, that these goals I am
> proposing are not something we would block on, any given item might be
> deferred to the next release if it?s not quite ready. Let me know if you
> have any additional major items you are planning to contribute towards 12.
>
> Thanks!
>
> -Jason
>
>
>
>
>
>
> _______________________________________________
> 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/20171214/a3cc838a/attachment-0001.html 

From brian.stansberry at redhat.com  Thu Dec 14 08:33:30 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 14 Dec 2017 07:33:30 -0600
Subject: [wildfly-dev] some JMX APIs cannot obtain an MBean that exists
In-Reply-To: <4AB28760-C9C3-4BCC-8A27-B709EAE46C6C@redhat.com>
References: <1472834285.54412596.1513203578265.JavaMail.zimbra@redhat.com>
	<4AB28760-C9C3-4BCC-8A27-B709EAE46C6C@redhat.com>
Message-ID: <CAPhbRDbazfBfnTQgC5s7UePcnqnxBUi23RMu7wSFJ5H34-6ywA@mail.gmail.com>

The "jboss.as:management-root=server" mbean *is* special. It represents the
management resource at address PathAddress.EMPTY_ADDRESS, and hence it has
a PathAddress that can't directly translate to an ObjectName. It has no
key/value pairs, and those are required in an ObjectName. So "
management-root=server" is a special hard coded name.

It doesn't surprise me that there's something broken in the handling of
that corner case. Can you file a WFCORE please? Please include the details
of your queryNames/queryMBeans calls.

Thanks,
Brian


On Thu, Dec 14, 2017 at 4:34 AM, Kabir Khan <kkhan at redhat.com> wrote:

> I have not tried your example, but I have an educated guess for what is
> going on.
>
> We use org.jboss.as.jmx.PluggableMBeanServerBuilder as an implementation
> for javax.management.MBeanServerBuilder which is what creates the
> platform mbean server. The resulting org.jboss.as.jmx.PluggableMBeanServerImpl
> is what allows the JMX subsystem to expose the management api via jmx.
>
> This gets set almost immediately in the boot process in the block at
> https://github.com/jboss-modules/jboss-modules/blob/1.
> x/src/main/java/org/jboss/modules/Main.java#L520.
>
> I would guess that your javaagent ends up calling getPlatformMBeanServer()
> before JBoss Modules has had a chance to do its stuff, and as the platform
> mbean server gets set on the first call to it, you end up with the default
> implementation of it. This will break things for other users wanting to use
> the pluggable mbean server too :)
>
> Some fixes that come to mind:
> - wait until we've had a chance to initialise before calling
> getPlatformMBeanServer() from your agent
> - make sure that the jmx module is on your javaagent's classpath and
> replicate what JBoss Modules does before calling getPlatformMBeanServer.
> For the server org.jboss.as.standalone is used as the boot module, this in
> turn pulls in the org.jboss.as.jmx module, which has the
> META-INF/services/org.jboss.as.jmx.PluggableMBeanServerBuilder file to
> load the proper implementation
>
> Thanks,
>
> Kabir
>
>
>
> > On 13 Dec 2017, at 22:19, John Mazzitelli <mazz at redhat.com> wrote:
> >
> > I'm seeing odd behavior with the JMX API implementation in Wildfly 11.
> >
> > If you grab this Makefile and two .java files I use for testing you can
> see it yourself - just put these in a tmp directory somewhere:
> >
> > wget https://raw.githubusercontent.com/jmazzitelli/test/master/
> javaagent/Makefile
> > wget https://raw.githubusercontent.com/jmazzitelli/test/master/
> javaagent/TestJavaAgent.java
> > wget https://raw.githubusercontent.com/jmazzitelli/test/master/
> javaagent/TestJavaAgentMXBean.java
> >
> > Then just run "make download-wildfly unzip-wildfly compile run" (make
> sure you don't have other WildFly servers running to avoid port conflicts)
> >
> > This runs WF 11 with a -javaagent attached. In the server output, you
> will see this:
> >
> > 16:31:05,290 INFO  [stdout] (Test Java Agent Thread)
> =============================================================
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) FIND INFORMATION
> ABOUT MBEAN: jboss.as:management-root=server
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)
> =============================================================
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) isRegistered:
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) true
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) getMBeanInfo:
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)   description: The
> root node of the server-level management model.
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)   #attributes: 19
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) getAttribute:
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)
> serverState=reload-required
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryNames:
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) []
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryMBeans:
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) []
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryNames(null,
> null):
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) FOUND IT: jboss.as:
> management-root=server
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)
> =============================================================
> >
> > You will see SOME JMX APIs can see the MBean "jboss.as:management-root=
> server",
> > but queryMBeans and queryNames canNOT (note the empty arrays []).
> >
> > But notice getMBeanInfo CAN see it - I can even get the serverState
> attribute value from that (you can see it is in reload-required state - I
> see the same behavior even if it was in "running" state).
> >
> > But again, queryMBeans returns nothing.
> >
> > Oddly, queryNames(null, null) DOES return it in the list (see the "FOUND
> IT" line). It is only if I specifically ask for it does it fail in the
> query API.
> >
> > Finally, note that it seems this MBean "jboss.as:management-root=server"
> is special - because it is specifically broke - if i switch to querying for
> "jboss.as:subsystem=transactions" it all works fine, even the query APIs:
> >
> > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) queryNames:
> > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) [jboss.as:
> subsystem=transactions]
> > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) queryMBeans:
> > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread)
> [org.jboss.as.controller.ModelController[jboss.as:subsystem=transactions]]
> >
> > This problem was seen by others as well (with the same MBean I'm trying
> to get) - see:
> >
> > https://github.com/prometheus/jmx_exporter/issues/89
> >
> > The person there claims queryNames is broke but queryMBeans is OK - that
> does not work in my example either. Neither query API works.
> >
> > I searched JIRA, found nothing related to this MBean not being queryable.
> > _______________________________________________
> > 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
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171214/a163e884/attachment.html 

From kkhan at redhat.com  Thu Dec 14 09:13:30 2017
From: kkhan at redhat.com (Kabir Khan)
Date: Thu, 14 Dec 2017 14:13:30 +0000
Subject: [wildfly-dev] some JMX APIs cannot obtain an MBean that exists
In-Reply-To: <CAPhbRDbazfBfnTQgC5s7UePcnqnxBUi23RMu7wSFJ5H34-6ywA@mail.gmail.com>
References: <1472834285.54412596.1513203578265.JavaMail.zimbra@redhat.com>
	<4AB28760-C9C3-4BCC-8A27-B709EAE46C6C@redhat.com>
	<CAPhbRDbazfBfnTQgC5s7UePcnqnxBUi23RMu7wSFJ5H34-6ywA@mail.gmail.com>
Message-ID: <EC791A2D-CFD1-41D5-9232-BBEC193B98EC@redhat.com>

Now I see I did not look properly at Mazz's example, sorry!

> On 14 Dec 2017, at 13:33, Brian Stansberry <brian.stansberry at redhat.com> wrote:
> 
> The "jboss.as:management-root=server" mbean *is* special. It represents the management resource at address PathAddress.EMPTY_ADDRESS, and hence it has a PathAddress that can't directly translate to an ObjectName. It has no key/value pairs, and those are required in an ObjectName. So "management-root=server" is a special hard coded name.
> 
> It doesn't surprise me that there's something broken in the handling of that corner case. Can you file a WFCORE please? Please include the details of your queryNames/queryMBeans calls.
> 
> Thanks,
> Brian
> 
> 
> On Thu, Dec 14, 2017 at 4:34 AM, Kabir Khan <kkhan at redhat.com> wrote:
> I have not tried your example, but I have an educated guess for what is going on.
> 
> We use org.jboss.as.jmx.PluggableMBeanServerBuilder as an implementation for javax.management.MBeanServerBuilder which is what creates the platform mbean server. The resulting org.jboss.as.jmx.PluggableMBeanServerImpl is what allows the JMX subsystem to expose the management api via jmx.
> 
> This gets set almost immediately in the boot process in the block at https://github.com/jboss-modules/jboss-modules/blob/1.x/src/main/java/org/jboss/modules/Main.java#L520.
> 
> I would guess that your javaagent ends up calling getPlatformMBeanServer() before JBoss Modules has had a chance to do its stuff, and as the platform mbean server gets set on the first call to it, you end up with the default implementation of it. This will break things for other users wanting to use the pluggable mbean server too :)
> 
> Some fixes that come to mind:
> - wait until we've had a chance to initialise before calling getPlatformMBeanServer() from your agent
> - make sure that the jmx module is on your javaagent's classpath and replicate what JBoss Modules does before calling getPlatformMBeanServer. For the server org.jboss.as.standalone is used as the boot module, this in turn pulls in the org.jboss.as.jmx module, which has the META-INF/services/org.jboss.as.jmx.PluggableMBeanServerBuilder file to load the proper implementation
> 
> Thanks,
> 
> Kabir
> 
> 
> 
> > On 13 Dec 2017, at 22:19, John Mazzitelli <mazz at redhat.com> wrote:
> >
> > I'm seeing odd behavior with the JMX API implementation in Wildfly 11.
> >
> > If you grab this Makefile and two .java files I use for testing you can see it yourself - just put these in a tmp directory somewhere:
> >
> > wget https://raw.githubusercontent.com/jmazzitelli/test/master/javaagent/Makefile
> > wget https://raw.githubusercontent.com/jmazzitelli/test/master/javaagent/TestJavaAgent.java
> > wget https://raw.githubusercontent.com/jmazzitelli/test/master/javaagent/TestJavaAgentMXBean.java
> >
> > Then just run "make download-wildfly unzip-wildfly compile run" (make sure you don't have other WildFly servers running to avoid port conflicts)
> >
> > This runs WF 11 with a -javaagent attached. In the server output, you will see this:
> >
> > 16:31:05,290 INFO  [stdout] (Test Java Agent Thread) =============================================================
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) FIND INFORMATION ABOUT MBEAN: jboss.as:management-root=server
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) =============================================================
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) isRegistered:
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) true
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) getMBeanInfo:
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)   description: The root node of the server-level management model.
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)   #attributes: 19
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) getAttribute:
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) serverState=reload-required
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryNames:
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) []
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryMBeans:
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) []
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryNames(null, null):
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) FOUND IT: jboss.as:management-root=server
> > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) =============================================================
> >
> > You will see SOME JMX APIs can see the MBean "jboss.as:management-root=server",
> > but queryMBeans and queryNames canNOT (note the empty arrays []).
> >
> > But notice getMBeanInfo CAN see it - I can even get the serverState attribute value from that (you can see it is in reload-required state - I see the same behavior even if it was in "running" state).
> >
> > But again, queryMBeans returns nothing.
> >
> > Oddly, queryNames(null, null) DOES return it in the list (see the "FOUND IT" line). It is only if I specifically ask for it does it fail in the query API.
> >
> > Finally, note that it seems this MBean "jboss.as:management-root=server" is special - because it is specifically broke - if i switch to querying for "jboss.as:subsystem=transactions" it all works fine, even the query APIs:
> >
> > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) queryNames:
> > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) [jboss.as:subsystem=transactions]
> > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) queryMBeans:
> > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) [org.jboss.as.controller.ModelController[jboss.as:subsystem=transactions]]
> >
> > This problem was seen by others as well (with the same MBean I'm trying to get) - see:
> >
> > https://github.com/prometheus/jmx_exporter/issues/89
> >
> > The person there claims queryNames is broke but queryMBeans is OK - that does not work in my example either. Neither query API works.
> >
> > I searched JIRA, found nothing related to this MBean not being queryable.
> > _______________________________________________
> > 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
> Manager, Senior Principal Software Engineer
> Red Hat



From anmiller at redhat.com  Thu Dec 14 11:43:31 2017
From: anmiller at redhat.com (Andrig Miller)
Date: Thu, 14 Dec 2017 09:43:31 -0700
Subject: [wildfly-dev] WildFly 12 Plans, EE8,
 and Move to Quarterly Iterative Releases
In-Reply-To: <CADGJaX9iy4HYihAf=mo+MzQMHnFC7RxvGc8QCveziswAZ_MCKw@mail.gmail.com>
References: <1C2615A5-9731-47EB-8FC2-FFBB4BA2C5FE@redhat.com>
	<CADGJaX9iy4HYihAf=mo+MzQMHnFC7RxvGc8QCveziswAZ_MCKw@mail.gmail.com>
Message-ID: <CAF1-sp62bd1Yf04mzBjT5ixZU2mmsb=NT-3Ks9u9BqbmLY825g@mail.gmail.com>

Nice write up on the performance for Hibernate Validator.

This stands out to me:  In a hot path, even the slightest instance creation
might introduce some undesired overhead.

This is what I emphasized during my recommendations slides in my
presentation on Tuesday.  The allocation rate is critical to good
performance and scalability.

Nice job.

Andy

On Thu, Dec 14, 2017 at 6:15 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi Jason,
>
> +1 for the plan to do time-boxed releases with a three month cadence.
>
> Maybe you could break down the schedule of a given release iteration a bit
> further, so e.g. if WF 12 is scheduled for February 28th, what are the mile
> stone dates for delivering PRs with new developments in WF itself,
> component upgrades, bugfixes etc.? Having a schedule like for instance
> OpenJDK has [1] would be helpful, so everyone knows what needs to be done
> by when.
>
> Speaking about BV 2.0 and HV 6, we're ready to deliver this (in last
> week's Hibernate team meeting we agreed on sending a PR for updating WF
> this week). We've done a couple of 6.0.x releases (at 6.0.6 atm.), i.e. it
> has been honed nicely and also performance has been improved significantly
> [2]. So I'd hope we can included this in 12 already?
>
> Thanks,
>
> --Gunnar
>
> [1] http://openjdk.java.net/projects/jdk/10/
> [2] http://in.relation.to/2017/10/31/bean-validation-benchmark-revisited/
>
> 2017-12-14 3:51 GMT+01:00 Jason Greene <jason.greene at redhat.com>:
>
>>
>> Hello Everyone,
>>
>> Release Model Changes
>> ????????????????????-
>> In order to bring new capabilities to the community quicker, we plan to
>> move to a more iterative time-boxed approach, starting with WildFly 12 (and
>> continuing with 13, 14, etc). By time-boxed, I mean the each release aims
>> to have a fixed and reliable delivery window that approximates a calendar
>> quarter. Since these time-frames are fixed, it?s important that any given
>> feature or improvement not hold up a release. To facilitate this we need to
>> make major changes to our development process. Currently development for
>> any enhancement is merged in chunks, as it progresses from inception to
>> completion. This means to have something worthy of release, we must either
>> block for its completion or roll it back. The latter is often difficult,
>> since at any given moment there are many features under active development,
>> and their respective implementations can become co-dependent. Additionally,
>> its common for component dependencies to start off as Alphas and/or Betas,
>> and we end up needing to wait for those components to hit Final before we
>> can cut the release.
>>
>> The solution to this problem is to rely more on topic branches, and only
>> merge fully completed work to master. By fully complete, I mean all PRs on
>> master should be fully developed, tested, and documented[1]. Additionally
>> any updated dependencies must only be against Final/GA components.
>>
>> This has a number of advantages:
>>
>> A. Master becomes always stable, always releasable. So at any given
>> moment we can decided to cut a release[1]
>> B. Nightly builds become way more usable, and a great feedback channel (a
>> release starts to have less importance)
>> C. If a feature takes longer than expected, no big deal, it will be
>> picked up in the next cycle[2]
>> D. Should anything cause a major regression, not caught in testing it
>> will be easier to revert, since the history will be cleaner
>>
>> Since in-progress work will need to be based on topic branches, custom
>> jobs on ci.wildfly.org will need to be relied upon instead of the
>> automated CI that happens when you submit a PR (although that?s still
>> important and still staying). Additionally if two changes/improvements are
>> interrelated, then they will need to either share a topic branch, or find a
>> way to construct the work independently (potentially adding and removing a
>> temporary construct until both are merged).
>>
>>
>> [1] To make it easier to associate documentation with the PR, we are
>> looking to move to an asciidoc based solution instead of confluence like we
>> utilize today.
>>
>> [2] While this is generally the case, there are some activities we can?t
>> avoid before releasing, such as ensuring a TCK run has completed.
>>
>> [3] An important aspect of C is that iterations have a short enough
>> cycle, such that the pressure to make a particular iteration is low enough
>> to avoid the urge to try and cram something in, and potentially compromise
>> quality (e.g. no docs etc).
>>
>>
>> Java EE8
>> ????????
>> As part of adopting this model, we aim to deliver Java EE8 in incremental
>> chunks. Adding support for specs individually in batches. As an example for
>> WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to
>> unfortunate restrictions in EE certification, we will need to have a
>> separate configuration profile or property to enable these additional APIs
>> until we complete full EE8 certification.
>>
>> Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
>> ????????????????????????
>> + Adopt new release model
>> + Java 9 improvements
>> + Servlet 4
>> + JSON-B (incorporating Yasoon)
>> + CDI 2
>> + JSF 2.3
>> + Metaspace usage improvements
>> + early/initial changes to accommodate the new provisioning effort (easy
>> slimming, updates, etc)
>>
>> Proposed WildFly 13 Goals (Very Tentative) [May 2018]
>> ???????????????????????????-
>> + New EE Security Spec
>> + Adoption of provisioning
>> + JPA 2.2
>> + JAX-RS 2.1
>> + BV 2.0
>> + Agroal inclusion
>>
>> Just to highlight that with this new model, that these goals I am
>> proposing are not something we would block on, any given item might be
>> deferred to the next release if it?s not quite ready. Let me know if you
>> have any additional major items you are planning to contribute towards 12.
>>
>> Thanks!
>>
>> -Jason
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>



-- 
Andrig (Andy) T. Miller
Global Platform Director, Middleware
Red Hat, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171214/23d37e4a/attachment-0001.html 

From fjuma at redhat.com  Thu Dec 14 13:10:16 2017
From: fjuma at redhat.com (Farah Juma)
Date: Thu, 14 Dec 2017 13:10:16 -0500
Subject: [wildfly-dev] Integration with Let's Encrypt
Message-ID: <CAFv3guRHTx4L9FMd8G1ephA41L7foa45aE-zvUiao1g_O1mOUg@mail.gmail.com>

As a follow-up to the new Elytron key-store management operations [1] that
allow for more advanced KeyStore manipulation, I've been looking into
integration with the Let's Encrypt certificate authority to add new
management operations to the key-store resource for obtaining signed
certificates, revoking them, and renewing them. I've created an analysis
document to get feedback on this [2]. Feel free to comment on the document.

Thanks,
Farah

[1]
https://developer.jboss.org/wiki/AnalysisDesign-AdvancedElytronKey-storeManipulationOperations
[2]
https://developer.jboss.org/wiki/AnalysisDesign-IntegrationWithTheLetsEncryptCertificateAuthority
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171214/470c9089/attachment.html 

From brian.stansberry at redhat.com  Thu Dec 14 16:23:12 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 14 Dec 2017 15:23:12 -0600
Subject: [wildfly-dev] Logging Changes
In-Reply-To: <CADGwLpgdeiPmxsda=26xi0_Rq1vj3axh-Bxa8qULpF9_SZGzog@mail.gmail.com>
References: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
	<CANghgrRrbV_ksi8FBOSQthc1XLsVrc-sNyBGz69tJFgD00GFiQ@mail.gmail.com>
	<CAPhbRDYr1yV1NVGxiuteM9wHnEZZE8PKzS7yD8mnCg1-EswWaQ@mail.gmail.com>
	<CADGwLpgfOhDfW_yE21=EdN5aA75qZNKYoSz=xdHXsYXQP+WqTw@mail.gmail.com>
	<CAPhbRDYG5gVLWPOTODiO0Wd5te57xJA2+zJyF6joNnB__ZcuDg@mail.gmail.com>
	<CADGwLpgdeiPmxsda=26xi0_Rq1vj3axh-Bxa8qULpF9_SZGzog@mail.gmail.com>
Message-ID: <CAPhbRDZKP5aBpJDVKCQJ+i+VEanmjxF2DQrO4UxsMpttuX8W9w@mail.gmail.com>

On Tue, Dec 12, 2017 at 2:18 PM, James Perkins <jperkins at redhat.com> wrote:

>
>
> On Tue, Dec 12, 2017 at 11:10 AM, Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>>
>>
>>>>> I'm not sure what counts as first in this context, but fwiw if a
>>>> logging subsystem is present during boot we always execute it's
>>>> Stage.RUNTIME steps first before proceeding on to doing the parallel
>>>> execution of the other subsystems. We could probably without too much
>>>> trouble get a bit more grimy, e.g. to get the subsystem ops to run before a
>>>> few others if they don't already. Beyond that I sense we wouldn't be
>>>> talking grimy, we'd be talking horrible. :)
>>>>
>>>
>>> Darran and I had a brief discussion about what we could do because at
>>> least parts of Elytron and logging are generally needed before other things
>>> are configured. Elytron would likely need to be first because logging will
>>> have to use capabilities from it.
>>>
>>> I've wondered if there should be a new Stage.PRE_RUNTIME type of stage,
>>> but I can also see where that may get abused.
>>>
>>
>> This is starting to smell bad.
>>
>> Elytron needs DS it seems, and DS needs ? and, well, this is why we use
>> MSC. :)  We hadn't had deps from logging to other subsystems before, which
>> is what made the minor boot op ordering tricks we do useful, but since we
>> now do, then we're really down to MSC. Boot op ordering tricks can help
>> optimize common cases like a logging subsystem not having elytron
>> dependencies, but I don't think we should try and create a duplicate MSC.
>>
>>
>
> Yes I definitely agree. I don't really think adding a new stage is a good
> idea.
>
> The only real reason for logging to need a dependency on Elytron would be
> to get an SSLContext for sending log messages over a socket. We don't
> currently have a socket-handler and the syslog handler doesn't currently
> support SSL. However the syslog server for access logging does.
>
> If we don't want to have logging rely on Elytron we'd just have to use the
> standard way of configuring an SSLContext.
>
>

I don't intend to advocate not relying on Elytron. But if a config does
that I think it means some logging stuff isn't available until MSC says it
is, and I guess that means queuing messages.

Is the queueing until the management op that installs the logging subsystem
commits? Which basically means until the end of boot? If so that's an
argument for splitting deployments out into a different chunk of boot ops
from the deployments.

BTW, I'm not sure why a domain server would be different from a standalone
one in terms of having to use JBoss Log Manager.

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171214/48f57aca/attachment.html 

From brian.stansberry at redhat.com  Thu Dec 14 16:28:34 2017
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 14 Dec 2017 15:28:34 -0600
Subject: [wildfly-dev] Logging Changes
In-Reply-To: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
References: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
Message-ID: <CAPhbRDaM+iMtjNX_S9JknzonQS0etE6X2HYWj6jXJ9QV8GUXPA@mail.gmail.com>

What would the system properties look like?

On Thu, Dec 7, 2017 at 2:02 PM, James Perkins <jperkins at redhat.com> wrote:

> Hello All,
> For WildFly 12 (maybe not until 13 at this stage) there are some thoughts
> on significantly changing the way logging is configured. Currently logging
> is initialized by reading a logging.properties file when JBoss Modules
> boots. While this works okay there are a few issues with this approach.
>
>
>    1. For boot logging (before the logging subsystem is initialized) you
>    can't use property expressions. This means when the logging subsystem
>    rewrites the logging.properties file with all expressions expanded.
>    2. Logging objects, such as handlers, cannot use resources from other
>    subsystems. For example there is a need for a socket-handler. With the
>    socket handler we need a way to get an SSL context from Elytron. There is
>    no way for this to be done using a logging.properties file for the boot log
>    configuration.
>    3. If the user want to manually change the logging configuration by
>    editing the XML they also have to edit the logging.properties. If not the
>    old configuration will be used until the next boot.
>
> It would be useful to introduce a way to queue log messages during boot
> [1]. Once the logging subsystem boot is complete the messages would be
> drained and sent to the new configuration. This of course isn't without
> it's own issues.
>
>
>    1. Messages appeared delayed when WildFly is booting. Essentially all
>    the boot messages are written at once so you see no messages, then all of
>    them at once.
>    2. A shutdown hook would have to be used in order to ensure errors
>    that cause a boot failure are logged.
>    3. This could get a little tricky with offline CLI as currently
>    logging is configured based on the logging.properties file
>    4. If users remove the logging subsystem there are more steps than
>    just removing logging subsystem to get logging working.
>    5. There will be a slight performance impact during boot. This can be
>    greatly reduced if the caller calculation is disabled. This can be done in
>    normal cases, but we likely can't make it the default. Note too this is
>    only a boot impact. Once the logging subsystem takes over, the performance
>    should be exactly the same as it was before.
>
> There is some good however too. This does open the door allowing users to
> more easily replace the log manager implementation for standalone servers.
> Currently we still, and maybe always will, require the JBoss Log Manager to
> be used for domain servers, the host controller and process controller.
>
> It also removes the need for a logging.properties for servers. I think
> this is a big bonus to the changes as logging for servers will only be
> configured in one place now. Domain will be a bit different, but we should
> likely introduce a logging subsystem on the host controller as well. I just
> don't think it makes much sense until we can sort out the issues above.
>
> The current idea is that boot logging will be configurable via system
> properties. These properties would have to be set in the JAVA_OPTS.
>
> I'm curious to hear any concerns others might have about this. This feels
> like a rather significant change so I'd rather get it right the first time.
>
> I have started a design doc, but it's not finalized yet. If you're curious
> however you can have at look at it on my topic branch [2]. You can also see
> some of the small changes I've made to get it working on WildFly Core on
> that branch.
>
>
> [1]: https://issues.jboss.org/browse/LOGMGR-177
> [2]: https://github.com/jamezp/wildfly-core/blob/
> bootstrap-logging/logging/bootstrap-logging.asciidoc
>
> --
> 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
>



-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171214/c7ee5948/attachment.html 

From jperkins at redhat.com  Thu Dec 14 16:41:53 2017
From: jperkins at redhat.com (James Perkins)
Date: Thu, 14 Dec 2017 13:41:53 -0800
Subject: [wildfly-dev] Logging Changes
In-Reply-To: <CAPhbRDZKP5aBpJDVKCQJ+i+VEanmjxF2DQrO4UxsMpttuX8W9w@mail.gmail.com>
References: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
	<CANghgrRrbV_ksi8FBOSQthc1XLsVrc-sNyBGz69tJFgD00GFiQ@mail.gmail.com>
	<CAPhbRDYr1yV1NVGxiuteM9wHnEZZE8PKzS7yD8mnCg1-EswWaQ@mail.gmail.com>
	<CADGwLpgfOhDfW_yE21=EdN5aA75qZNKYoSz=xdHXsYXQP+WqTw@mail.gmail.com>
	<CAPhbRDYG5gVLWPOTODiO0Wd5te57xJA2+zJyF6joNnB__ZcuDg@mail.gmail.com>
	<CADGwLpgdeiPmxsda=26xi0_Rq1vj3axh-Bxa8qULpF9_SZGzog@mail.gmail.com>
	<CAPhbRDZKP5aBpJDVKCQJ+i+VEanmjxF2DQrO4UxsMpttuX8W9w@mail.gmail.com>
Message-ID: <CADGwLpgF0okp6-6318aUYxWXArSxKqRYmXh2xciCjsfr1C60YA@mail.gmail.com>

On Thu, Dec 14, 2017 at 1:23 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> On Tue, Dec 12, 2017 at 2:18 PM, James Perkins <jperkins at redhat.com>
> wrote:
>
>>
>>
>> On Tue, Dec 12, 2017 at 11:10 AM, Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>>>
>>>
>>>>>> I'm not sure what counts as first in this context, but fwiw if a
>>>>> logging subsystem is present during boot we always execute it's
>>>>> Stage.RUNTIME steps first before proceeding on to doing the parallel
>>>>> execution of the other subsystems. We could probably without too much
>>>>> trouble get a bit more grimy, e.g. to get the subsystem ops to run before a
>>>>> few others if they don't already. Beyond that I sense we wouldn't be
>>>>> talking grimy, we'd be talking horrible. :)
>>>>>
>>>>
>>>> Darran and I had a brief discussion about what we could do because at
>>>> least parts of Elytron and logging are generally needed before other things
>>>> are configured. Elytron would likely need to be first because logging will
>>>> have to use capabilities from it.
>>>>
>>>> I've wondered if there should be a new Stage.PRE_RUNTIME type of stage,
>>>> but I can also see where that may get abused.
>>>>
>>>
>>> This is starting to smell bad.
>>>
>>> Elytron needs DS it seems, and DS needs ? and, well, this is why we use
>>> MSC. :)  We hadn't had deps from logging to other subsystems before, which
>>> is what made the minor boot op ordering tricks we do useful, but since we
>>> now do, then we're really down to MSC. Boot op ordering tricks can help
>>> optimize common cases like a logging subsystem not having elytron
>>> dependencies, but I don't think we should try and create a duplicate MSC.
>>>
>>>
>>
>> Yes I definitely agree. I don't really think adding a new stage is a good
>> idea.
>>
>> The only real reason for logging to need a dependency on Elytron would be
>> to get an SSLContext for sending log messages over a socket. We don't
>> currently have a socket-handler and the syslog handler doesn't currently
>> support SSL. However the syslog server for access logging does.
>>
>> If we don't want to have logging rely on Elytron we'd just have to use
>> the standard way of configuring an SSLContext.
>>
>>
>
> I don't intend to advocate not relying on Elytron. But if a config does
> that I think it means some logging stuff isn't available until MSC says it
> is, and I guess that means queuing messages.
>
> Is the queueing until the management op that installs the logging
> subsystem commits? Which basically means until the end of boot? If so
> that's an argument for splitting deployments out into a different chunk of
> boot ops from the deployments.
>

Yes. Log messages would be queued until the logging subsystem commits.
There will also have to be some kind of way to discover there is no logging
subsystem and fallback to a logging.properties file.

Splitting deployments out would probably have some benefit as it would cut
down on the number of log messages. Currently if you set the level to
something like DEBUG, which is what we'll have to default to in WildFly, it
effectively sets the root logger to that level until the configuration has
been completed. Likely not a huge deal, but something to consider for
debugging/tracing with log messages.


>
> BTW, I'm not sure why a domain server would be different from a standalone
> one in terms of having to use JBoss Log Manager.
>

Servers within a domain really shouldn't be too much of an issue. It's
mainly the process controller and host controller I was speaking about that
might be a bit different as they will still be controlled by a
logging.properties file still. There is potential for the console messages
to appear out of order I suppose too. Only if the console handler is used
for all servers, the host controller and the process controller though.


>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>



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

From jperkins at redhat.com  Thu Dec 14 16:49:20 2017
From: jperkins at redhat.com (James Perkins)
Date: Thu, 14 Dec 2017 13:49:20 -0800
Subject: [wildfly-dev] Logging Changes
In-Reply-To: <CAPhbRDaM+iMtjNX_S9JknzonQS0etE6X2HYWj6jXJ9QV8GUXPA@mail.gmail.com>
References: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
	<CAPhbRDaM+iMtjNX_S9JknzonQS0etE6X2HYWj6jXJ9QV8GUXPA@mail.gmail.com>
Message-ID: <CADGwLpguQ8p+HFwCYXwKq8afn7W_qTR8-nZ-O3cp+n52q08v=A@mail.gmail.com>

On Thu, Dec 14, 2017 at 1:28 PM, Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> What would the system properties look like?
>

I'm trying to use as few as possible, but right now they are:

* org.jboss.logmanager.bootstrap.enabled - A boolean property that
determines whether or not the queuing should be done.
* org.jboss.logmanager.bootstrap.level - The log level, set on the root
logger, that messages should be logged at. The default is DEBUG for WildFly.
* org.jboss.logmanager.bootstrap.queue-size - The default size of queue.
The default is 10,000 and any messages after that will still be logged,
however the first message is removed from the stack.
* org.jboss.logmanager.bootstrap.calculate.caller - A boolean property that
indicates whether or not the caller should be calculated before the message
is queued. In WildFly we'll have this disabled by default for performance.
* org.jboss.logmanager.bootstrap.fallback.config - This one may or may not
stay. It will likely provide a path to the configuration file to use if a
fallback is needed. A fallback will occur if the JVM exists before the
logging subsystem is comitted or the logging subsystem is not available.


>
> On Thu, Dec 7, 2017 at 2:02 PM, James Perkins <jperkins at redhat.com> wrote:
>
>> Hello All,
>> For WildFly 12 (maybe not until 13 at this stage) there are some thoughts
>> on significantly changing the way logging is configured. Currently logging
>> is initialized by reading a logging.properties file when JBoss Modules
>> boots. While this works okay there are a few issues with this approach.
>>
>>
>>    1. For boot logging (before the logging subsystem is initialized) you
>>    can't use property expressions. This means when the logging subsystem
>>    rewrites the logging.properties file with all expressions expanded.
>>    2. Logging objects, such as handlers, cannot use resources from other
>>    subsystems. For example there is a need for a socket-handler. With the
>>    socket handler we need a way to get an SSL context from Elytron. There is
>>    no way for this to be done using a logging.properties file for the boot log
>>    configuration.
>>    3. If the user want to manually change the logging configuration by
>>    editing the XML they also have to edit the logging.properties. If not the
>>    old configuration will be used until the next boot.
>>
>> It would be useful to introduce a way to queue log messages during boot
>> [1]. Once the logging subsystem boot is complete the messages would be
>> drained and sent to the new configuration. This of course isn't without
>> it's own issues.
>>
>>
>>    1. Messages appeared delayed when WildFly is booting. Essentially all
>>    the boot messages are written at once so you see no messages, then all of
>>    them at once.
>>    2. A shutdown hook would have to be used in order to ensure errors
>>    that cause a boot failure are logged.
>>    3. This could get a little tricky with offline CLI as currently
>>    logging is configured based on the logging.properties file
>>    4. If users remove the logging subsystem there are more steps than
>>    just removing logging subsystem to get logging working.
>>    5. There will be a slight performance impact during boot. This can be
>>    greatly reduced if the caller calculation is disabled. This can be done in
>>    normal cases, but we likely can't make it the default. Note too this is
>>    only a boot impact. Once the logging subsystem takes over, the performance
>>    should be exactly the same as it was before.
>>
>> There is some good however too. This does open the door allowing users to
>> more easily replace the log manager implementation for standalone servers.
>> Currently we still, and maybe always will, require the JBoss Log Manager to
>> be used for domain servers, the host controller and process controller.
>>
>> It also removes the need for a logging.properties for servers. I think
>> this is a big bonus to the changes as logging for servers will only be
>> configured in one place now. Domain will be a bit different, but we should
>> likely introduce a logging subsystem on the host controller as well. I just
>> don't think it makes much sense until we can sort out the issues above.
>>
>> The current idea is that boot logging will be configurable via system
>> properties. These properties would have to be set in the JAVA_OPTS.
>>
>> I'm curious to hear any concerns others might have about this. This feels
>> like a rather significant change so I'd rather get it right the first time.
>>
>> I have started a design doc, but it's not finalized yet. If you're
>> curious however you can have at look at it on my topic branch [2]. You can
>> also see some of the small changes I've made to get it working on WildFly
>> Core on that branch.
>>
>>
>> [1]: https://issues.jboss.org/browse/LOGMGR-177
>> [2]: https://github.com/jamezp/wildfly-core/blob/bootstrap-
>> logging/logging/bootstrap-logging.asciidoc
>>
>> --
>> 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
>>
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>



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

From jason.greene at redhat.com  Thu Dec 14 18:16:56 2017
From: jason.greene at redhat.com (Jason Greene)
Date: Thu, 14 Dec 2017 17:16:56 -0600
Subject: [wildfly-dev] WildFly 12 Plans, EE8,
 and Move to Quarterly Iterative Releases
In-Reply-To: <8d12f567-f6b2-6504-bd11-dd2398ef659b@gmail.com>
References: <1C2615A5-9731-47EB-8FC2-FFBB4BA2C5FE@redhat.com>
	<8d12f567-f6b2-6504-bd11-dd2398ef659b@gmail.com>
Message-ID: <BC2B34CD-541C-428B-814D-8D2B7B9F152F@redhat.com>


> On Dec 13, 2017, at 11:32 PM, Jaikiran Pai <jai.forums2013 at gmail.com> wrote:
> 
> Hi Jason,
> 
> Looks good in terms of quicker releases.
> 
> A related question, given this proposal, would it mean there will never 
> be Alpha, Beta, CR of WildFly releases anymore?

So with the master branch becoming always stable, and with the short windows I think Alphas and Betas are largely superseded by the nightly builds (effectively there is a release every night!). However if there is a strong desire for a Beta or a CR we could cut one. The overhead is small seeing as you can just take any commit from master.

> Furthermore, every 
> release starting WildFly 12 will now be a major release (in terms of 
> version numbers and even feature/changes)? What I mean is, once WildFly 
> 12 is released, there won't be any more releases of 12.x (for example, 
> 12.1.0 etc?)?

We would still do interim releases but only on-demand as needed, when there is a major bug (or bugs) that can?t wait for the next cycle. Additionally as part of the provisioning work we are working on, we aim to have the ability  for overlay delivery streams that are external to the official delivery. As an example, the BV/HV project might want to provide a ?latest? stream that you can subscribe to that always gives you the absolute latest HV version before its formally brought into WF master. 

> 
> P.S: Unrelated - is there any issue with mail delivery to this list. I 
> received this mail just a few minutes back while the mail actually seems 
> to have been sent a couple of hours back?

Yes, lists.jboss.org <http://lists.jboss.org/> is having delays. Sorry for the inconvenience. It?s being worked on and will hopefully be resolved soon.

> 
> -Jaikiran
> 
> 
> On 14/12/17 8:21 AM, Jason Greene wrote:
>> Hello Everyone,
>> 
>> Release Model Changes
>> ????????????????????-
>> In order to bring new capabilities to the community quicker, we plan to move to a more iterative time-boxed approach, starting with WildFly 12 (and continuing with 13, 14, etc). By time-boxed, I mean the each release aims to have a fixed and reliable delivery window that approximates a calendar quarter. Since these time-frames are fixed, it?s important that any given feature or improvement not hold up a release. To facilitate this we need to make major changes to our development process. Currently development for any enhancement is merged in chunks, as it progresses from inception to completion. This means to have something worthy of release, we must either block for its completion or roll it back. The latter is often difficult, since at any given moment there are many features under active development, and their respective implementations can become co-dependent. Additionally, its common for component dependencies to start off as Alphas and/or Betas, and we end up needing to wait for those components to hit Final before we can cut the release.
>> 
>> The solution to this problem is to rely more on topic branches, and only merge fully completed work to master. By fully complete, I mean all PRs on master should be fully developed, tested, and documented[1]. Additionally any updated dependencies must only be against Final/GA components.
>> 
>> This has a number of advantages:
>> 
>> A. Master becomes always stable, always releasable. So at any given moment we can decided to cut a release[1]
>> B. Nightly builds become way more usable, and a great feedback channel (a release starts to have less importance)
>> C. If a feature takes longer than expected, no big deal, it will be picked up in the next cycle[2]
>> D. Should anything cause a major regression, not caught in testing it will be easier to revert, since the history will be cleaner
>> 
>> Since in-progress work will need to be based on topic branches, custom jobs on ci.wildfly.org will need to be relied upon instead of the automated CI that happens when you submit a PR (although that?s still important and still staying). Additionally if two changes/improvements are interrelated, then they will need to either share a topic branch, or find a way to construct the work independently (potentially adding and removing a temporary construct until both are merged).
>> 
>> 
>> [1] To make it easier to associate documentation with the PR, we are looking to move to an asciidoc based solution instead of confluence like we utilize today.
>> 
>> [2] While this is generally the case, there are some activities we can?t avoid before releasing, such as ensuring a TCK run has completed.
>> 
>> [3] An important aspect of C is that iterations have a short enough cycle, such that the pressure to make a particular iteration is low enough to avoid the urge to try and cram something in, and potentially compromise quality (e.g. no docs etc).
>> 
>> 
>> Java EE8
>> ????????
>> As part of adopting this model, we aim to deliver Java EE8 in incremental chunks. Adding support for specs individually in batches. As an example for WildFly 12, I propose we target Servlet 4, JSON-B, and CDI. Due to unfortunate restrictions in EE certification, we will need to have a separate configuration profile or property to enable these additional APIs until we complete full EE8 certification.
>> 
>> Proposed WildFly 12 Goals [Target Release Date = Feb 28, 2018]
>> ????????????????????????
>> + Adopt new release model
>> + Java 9 improvements
>> + Servlet 4
>> + JSON-B (incorporating Yasoon)
>> + CDI 2
>> + JSF 2.3
>> + Metaspace usage improvements
>> + early/initial changes to accommodate the new provisioning effort (easy slimming, updates, etc)
>> 
>> Proposed WildFly 13 Goals (Very Tentative) [May 2018]
>> ???????????????????????????-
>> + New EE Security Spec
>> + Adoption of provisioning
>> + JPA 2.2
>> + JAX-RS 2.1
>> + BV 2.0
>> + Agroal inclusion
>> 
>> Just to highlight that with this new model, that these goals I am proposing are not something we would block on, any given item might be deferred to the next release if it?s not quite ready. Let me know if you have any additional major items you are planning to contribute towards 12.
>> 
>> Thanks!
>> 
>> -Jason
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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/20171214/327ad3b4/attachment-0001.html 

From kwills at redhat.com  Thu Dec 14 22:24:02 2017
From: kwills at redhat.com (Ken Wills)
Date: Fri, 15 Dec 2017 03:24:02 +0000
Subject: [wildfly-dev] Logging Changes
In-Reply-To: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
References: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
Message-ID: <CAMw35_q1VCefCMSJtUtoWN1OvF9Oqrh1TPyLqF8YpyjnOWjMXA@mail.gmail.com>

I'm not so clear on a lot of the gritty details here, but I would caution
against any sort of shutdown hook usage. For the embedded use case this is
a bit of a problem, since they stack up until the user finally quits. There
is a fairly clear need for an abstraction that executes on some sort of
"executed unit of work," basis vs actually ends up calling exit().

Ken

On Thu, Dec 7, 2017 at 3:58 PM James Perkins <jperkins at redhat.com> wrote:

> Hello All,
> For WildFly 12 (maybe not until 13 at this stage) there are some thoughts
> on significantly changing the way logging is configured. Currently logging
> is initialized by reading a logging.properties file when JBoss Modules
> boots. While this works okay there are a few issues with this approach.
>
>
>    1. For boot logging (before the logging subsystem is initialized) you
>    can't use property expressions. This means when the logging subsystem
>    rewrites the logging.properties file with all expressions expanded.
>    2. Logging objects, such as handlers, cannot use resources from other
>    subsystems. For example there is a need for a socket-handler. With the
>    socket handler we need a way to get an SSL context from Elytron. There is
>    no way for this to be done using a logging.properties file for the boot log
>    configuration.
>    3. If the user want to manually change the logging configuration by
>    editing the XML they also have to edit the logging.properties. If not the
>    old configuration will be used until the next boot.
>
> It would be useful to introduce a way to queue log messages during boot
> [1]. Once the logging subsystem boot is complete the messages would be
> drained and sent to the new configuration. This of course isn't without
> it's own issues.
>
>
>    1. Messages appeared delayed when WildFly is booting. Essentially all
>    the boot messages are written at once so you see no messages, then all of
>    them at once.
>    2. A shutdown hook would have to be used in order to ensure errors
>    that cause a boot failure are logged.
>    3. This could get a little tricky with offline CLI as currently
>    logging is configured based on the logging.properties file
>    4. If users remove the logging subsystem there are more steps than
>    just removing logging subsystem to get logging working.
>    5. There will be a slight performance impact during boot. This can be
>    greatly reduced if the caller calculation is disabled. This can be done in
>    normal cases, but we likely can't make it the default. Note too this is
>    only a boot impact. Once the logging subsystem takes over, the performance
>    should be exactly the same as it was before.
>
> There is some good however too. This does open the door allowing users to
> more easily replace the log manager implementation for standalone servers.
> Currently we still, and maybe always will, require the JBoss Log Manager to
> be used for domain servers, the host controller and process controller.
>
> It also removes the need for a logging.properties for servers. I think
> this is a big bonus to the changes as logging for servers will only be
> configured in one place now. Domain will be a bit different, but we should
> likely introduce a logging subsystem on the host controller as well. I just
> don't think it makes much sense until we can sort out the issues above.
>
> The current idea is that boot logging will be configurable via system
> properties. These properties would have to be set in the JAVA_OPTS.
>
> I'm curious to hear any concerns others might have about this. This feels
> like a rather significant change so I'd rather get it right the first time.
>
> I have started a design doc, but it's not finalized yet. If you're curious
> however you can have at look at it on my topic branch [2]. You can also see
> some of the small changes I've made to get it working on WildFly Core on
> that branch.
>
>
> [1]: https://issues.jboss.org/browse/LOGMGR-177
> [2]:
> https://github.com/jamezp/wildfly-core/blob/bootstrap-logging/logging/bootstrap-logging.asciidoc
>
> --
> 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/20171215/808e884f/attachment.html 

From jai.forums2013 at gmail.com  Fri Dec 15 00:26:45 2017
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Fri, 15 Dec 2017 10:56:45 +0530
Subject: [wildfly-dev] WildFly 12 Plans, EE8,
 and Move to Quarterly Iterative Releases
In-Reply-To: <BC2B34CD-541C-428B-814D-8D2B7B9F152F@redhat.com>
References: <1C2615A5-9731-47EB-8FC2-FFBB4BA2C5FE@redhat.com>
	<8d12f567-f6b2-6504-bd11-dd2398ef659b@gmail.com>
	<BC2B34CD-541C-428B-814D-8D2B7B9F152F@redhat.com>
Message-ID: <d7693f8b-0fe9-5396-b71f-fa3b0ab37569@gmail.com>


On 15/12/17 4:46 AM, Jason Greene wrote:
>
>> On Dec 13, 2017, at 11:32 PM, Jaikiran Pai <jai.forums2013 at gmail.com 
>> <mailto:jai.forums2013 at gmail.com>> wrote:
>>
>> Hi Jason,
>>
>> Looks good in terms of quicker releases.
>>
>> A related question, given this proposal, would it mean there will never
>> be Alpha, Beta, CR of WildFly releases anymore?
>
> So with the master branch becoming always stable, and with the short 
> windows I think Alphas and Betas are largely superseded by the nightly 
> builds (effectively there is a release every night!). However if there 
> is a strong desire for a Beta or a CR we could cut one. The overhead 
> is small seeing as you can just take any commit from master.
>
My personal opinion based on what I have seen in the forums is that 
there's very few users who really download a nightly build to try out 
new things. I do know there are some who do that and do report issues, 
but most of the times, it's only when there's some kind of announcement 
about a "release", they try out the version. So I think having a CR (if 
not a Beta) a couple of weeks before the actual release, backed by an 
announcement about the CR would help get some real usage for that version.

-Jaikiran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171215/fd49fa03/attachment.html 

From dometec at gmail.com  Fri Dec 15 03:39:21 2017
From: dometec at gmail.com (Domenico Briganti)
Date: Fri, 15 Dec 2017 09:39:21 +0100
Subject: [wildfly-dev] Add persistend store to infinispan via CLI fail
Message-ID: <1513327161.6192.3.camel@gmail.com>

Hi all!

 I'm trying to configure a persistent file for a local-cache in
widlfly-11 via CLI but fail, it however works if I put the
configuration directly on standalone.xml:

<local-cache...
  <file-store path="authtoken.dat" relative-to="jboss.home.dir"
passivation="false" preload="true" purge="false"/>

I try this CLI command in a fresh wildfly-11 installation, and the last
fail:
 
[standalone at localhost:9990 /] /subsystem=infinispan/cache-
container=reservation:add

{"outcome" => "success"}


[standalone at localhost:9990 /] /subsystem=infinispan/cache-
container=reservation/local-cache=authtoken:add(statistics-
enabled=true)

{"outcome" => "success"}


[standalone at localhost:9990 /] /subsystem=infinispan/cache-
container=reservation/local-
cache=authtoken/store=file:add(path=authtoken.dat,relative-
to=jboss.home.dir,passivation=false,preload=true,purge=true)

{
????"outcome" => "failed",
????"failure-description" => "WFLYCTL0158: Operation handler failed:
org.jboss.msc.service.DuplicateServiceException: Service
org.wildfly.clustering.infinispan.cache.store.reservation.authtoken is
already registered",
????"rolled-back" => true
}


Maybe I submit a wrong CLI command?

Thanks,
Domenico Briganti



From tomaz.cerar at gmail.com  Fri Dec 15 05:37:03 2017
From: tomaz.cerar at gmail.com (=?utf-8?Q?Toma=C5=BE_Cerar?=)
Date: Fri, 15 Dec 2017 11:37:03 +0100
Subject: [wildfly-dev] Add persistend store to infinispan via CLI fail
In-Reply-To: <1513327161.6192.3.camel@gmail.com>
References: <1513327161.6192.3.camel@gmail.com>
Message-ID: <5a33a5d9.0587df0a.33936.515c@mx.google.com>

Does it work if you run you commands in batch?

--
Toma?

From: Domenico Briganti
Sent: petek, 15. december 2017 09:39
To: wildfly-dev at lists.jboss.org
Subject: [wildfly-dev] Add persistend store to infinispan via CLI fail

Hi all!

 I'm trying to configure a persistent file for a local-cache in
widlfly-11 via CLI but fail, it however works if I put the
configuration directly on standalone.xml:

<local-cache...
  <file-store path="authtoken.dat" relative-to="jboss.home.dir"
passivation="false" preload="true" purge="false"/>

I try this CLI command in a fresh wildfly-11 installation, and the last
fail:
 
[standalone at localhost:9990 /] /subsystem=infinispan/cache-
container=reservation:add

{"outcome" => "success"}


[standalone at localhost:9990 /] /subsystem=infinispan/cache-
container=reservation/local-cache=authtoken:add(statistics-
enabled=true)

{"outcome" => "success"}


[standalone at localhost:9990 /] /subsystem=infinispan/cache-
container=reservation/local-
cache=authtoken/store=file:add(path=authtoken.dat,relative-
to=jboss.home.dir,passivation=false,preload=true,purge=true)

{
????"outcome" => "failed",
????"failure-description" => "WFLYCTL0158: Operation handler failed:
org.jboss.msc.service.DuplicateServiceException: Service
org.wildfly.clustering.infinispan.cache.store.reservation.authtoken is
already registered",
????"rolled-back" => true
}


Maybe I submit a wrong CLI command?

Thanks,
Domenico Briganti


_______________________________________________
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/20171215/766830cb/attachment-0001.html 

From dometec at gmail.com  Fri Dec 15 07:37:20 2017
From: dometec at gmail.com (Domenico Briganti)
Date: Fri, 15 Dec 2017 13:37:20 +0100
Subject: [wildfly-dev] Add persistend store to infinispan via CLI fail
In-Reply-To: <5a33a5d9.0587df0a.33936.515c@mx.google.com>
References: <1513327161.6192.3.camel@gmail.com>
	<5a33a5d9.0587df0a.33936.515c@mx.google.com>
Message-ID: <1513341440.6192.6.camel@gmail.com>

Yes! it work in batch mode. See the attach cli file.

But it should works also in interactive mode, correct?


Domenico


Il giorno ven, 15/12/2017 alle 11.37 +0100, Toma? Cerar ha scritto:
> Does it work if you run you commands in batch?
> ?
> --
> Toma?
> ?
> From: Domenico Briganti
> Sent: petek, 15. december 2017 09:39
> To: wildfly-dev at lists.jboss.org
> Subject: [wildfly-dev] Add persistend store to infinispan via CLI
> fail
> ?file:///opt/wildfly-11.0.0.Final_Bravo/test.cli
> Hi all!
> ?
> I'm trying to configure a persistent file for a local-cache in
> widlfly-11 via CLI but fail, it however works if I put the
> configuration directly on standalone.xml:
> ?
> <local-cache...
> ? <file-store path="authtoken.dat" relative-to="jboss.home.dir"
> passivation="false" preload="true" purge="false"/>
> ?
> I try this CLI command in a fresh wildfly-11 installation, and the
> last
> fail:
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-
> container=reservation:add
> ?
> {"outcome" => "success"}
> ?
> ?
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-
> container=reservation/local-cache=authtoken:add(statistics-
> enabled=true)
> ?
> {"outcome" => "success"}
> ?
> ?
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-
> container=reservation/local-
> cache=authtoken/store=file:add(path=authtoken.dat,relative-
> to=jboss.home.dir,passivation=false,preload=true,purge=true)
> ?
> {
> ????"outcome" => "failed",
> ????"failure-description" => "WFLYCTL0158: Operation handler failed:
> org.jboss.msc.service.DuplicateServiceException: Service
> org.wildfly.clustering.infinispan.cache.store.reservation.authtoken
> is
> already registered",
> ????"rolled-back" => true
> }
> ?
> ?
> Maybe I submit a wrong CLI command?
> ?
> Thanks,
> Domenico Briganti
> ?
> ?
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> ?
-------------- next part --------------
batch

/subsystem=infinispan/cache-container=reservation:add
 
/subsystem=infinispan/cache-container=reservation/local-cache=authtoken:add(statistics-enabled=true) 
 
/subsystem=infinispan/cache-container=reservation/local-cache=authtoken/store=file:add(path=authtoken.dat,relative-to=jboss.home.dir,passivation=false,preload=true,purge=true)

run-batch


From lponce at redhat.com  Fri Dec 15 08:07:33 2017
From: lponce at redhat.com (Lucas Ponce)
Date: Fri, 15 Dec 2017 14:07:33 +0100
Subject: [wildfly-dev] some JMX APIs cannot obtain an MBean that exists
In-Reply-To: <EC791A2D-CFD1-41D5-9232-BBEC193B98EC@redhat.com>
References: <1472834285.54412596.1513203578265.JavaMail.zimbra@redhat.com>
	<4AB28760-C9C3-4BCC-8A27-B709EAE46C6C@redhat.com>
	<CAPhbRDbazfBfnTQgC5s7UePcnqnxBUi23RMu7wSFJ5H34-6ywA@mail.gmail.com>
	<EC791A2D-CFD1-41D5-9232-BBEC193B98EC@redhat.com>
Message-ID: <CAGUuq3WTbYhuG+MC4B+4uM=iRieMHi_3vETqsrdsaZTD_GAX_A@mail.gmail.com>

Hi all,

This is the JIRA with more details and pointers to the examples about how
to reproduce

https://issues.jboss.org/browse/WFCORE-3461

Thanks,
Lucas

On Thu, Dec 14, 2017 at 3:13 PM, Kabir Khan <kkhan at redhat.com> wrote:

> Now I see I did not look properly at Mazz's example, sorry!
>
> > On 14 Dec 2017, at 13:33, Brian Stansberry <brian.stansberry at redhat.com>
> wrote:
> >
> > The "jboss.as:management-root=server" mbean *is* special. It represents
> the management resource at address PathAddress.EMPTY_ADDRESS, and hence it
> has a PathAddress that can't directly translate to an ObjectName. It has no
> key/value pairs, and those are required in an ObjectName. So
> "management-root=server" is a special hard coded name.
> >
> > It doesn't surprise me that there's something broken in the handling of
> that corner case. Can you file a WFCORE please? Please include the details
> of your queryNames/queryMBeans calls.
> >
> > Thanks,
> > Brian
> >
> >
> > On Thu, Dec 14, 2017 at 4:34 AM, Kabir Khan <kkhan at redhat.com> wrote:
> > I have not tried your example, but I have an educated guess for what is
> going on.
> >
> > We use org.jboss.as.jmx.PluggableMBeanServerBuilder as an
> implementation for javax.management.MBeanServerBuilder which is what
> creates the platform mbean server. The resulting org.jboss.as.jmx.PluggableMBeanServerImpl
> is what allows the JMX subsystem to expose the management api via jmx.
> >
> > This gets set almost immediately in the boot process in the block at
> https://github.com/jboss-modules/jboss-modules/blob/1.
> x/src/main/java/org/jboss/modules/Main.java#L520.
> >
> > I would guess that your javaagent ends up calling
> getPlatformMBeanServer() before JBoss Modules has had a chance to do its
> stuff, and as the platform mbean server gets set on the first call to it,
> you end up with the default implementation of it. This will break things
> for other users wanting to use the pluggable mbean server too :)
> >
> > Some fixes that come to mind:
> > - wait until we've had a chance to initialise before calling
> getPlatformMBeanServer() from your agent
> > - make sure that the jmx module is on your javaagent's classpath and
> replicate what JBoss Modules does before calling getPlatformMBeanServer.
> For the server org.jboss.as.standalone is used as the boot module, this in
> turn pulls in the org.jboss.as.jmx module, which has the
> META-INF/services/org.jboss.as.jmx.PluggableMBeanServerBuilder file to
> load the proper implementation
> >
> > Thanks,
> >
> > Kabir
> >
> >
> >
> > > On 13 Dec 2017, at 22:19, John Mazzitelli <mazz at redhat.com> wrote:
> > >
> > > I'm seeing odd behavior with the JMX API implementation in Wildfly 11.
> > >
> > > If you grab this Makefile and two .java files I use for testing you
> can see it yourself - just put these in a tmp directory somewhere:
> > >
> > > wget https://raw.githubusercontent.com/jmazzitelli/test/master/
> javaagent/Makefile
> > > wget https://raw.githubusercontent.com/jmazzitelli/test/master/
> javaagent/TestJavaAgent.java
> > > wget https://raw.githubusercontent.com/jmazzitelli/test/master/
> javaagent/TestJavaAgentMXBean.java
> > >
> > > Then just run "make download-wildfly unzip-wildfly compile run" (make
> sure you don't have other WildFly servers running to avoid port conflicts)
> > >
> > > This runs WF 11 with a -javaagent attached. In the server output, you
> will see this:
> > >
> > > 16:31:05,290 INFO  [stdout] (Test Java Agent Thread)
> =============================================================
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) FIND INFORMATION
> ABOUT MBEAN: jboss.as:management-root=server
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)
> =============================================================
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) isRegistered:
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) true
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) getMBeanInfo:
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)   description:
> The root node of the server-level management model.
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)   #attributes: 19
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) getAttribute:
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)
> serverState=reload-required
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryNames:
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) []
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryMBeans:
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) []
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) queryNames(null,
> null):
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread) FOUND IT:
> jboss.as:management-root=server
> > > 16:31:05,291 INFO  [stdout] (Test Java Agent Thread)
> =============================================================
> > >
> > > You will see SOME JMX APIs can see the MBean "jboss.as:
> management-root=server",
> > > but queryMBeans and queryNames canNOT (note the empty arrays []).
> > >
> > > But notice getMBeanInfo CAN see it - I can even get the serverState
> attribute value from that (you can see it is in reload-required state - I
> see the same behavior even if it was in "running" state).
> > >
> > > But again, queryMBeans returns nothing.
> > >
> > > Oddly, queryNames(null, null) DOES return it in the list (see the
> "FOUND IT" line). It is only if I specifically ask for it does it fail in
> the query API.
> > >
> > > Finally, note that it seems this MBean "jboss.as:management-root=server"
> is special - because it is specifically broke - if i switch to querying for
> "jboss.as:subsystem=transactions" it all works fine, even the query APIs:
> > >
> > > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) queryNames:
> > > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) [jboss.as:
> subsystem=transactions]
> > > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread) queryMBeans:
> > > 17:16:39,541 INFO  [stdout] (Test Java Agent Thread)
> [org.jboss.as.controller.ModelController[jboss.as:subsystem=transactions]]
> > >
> > > This problem was seen by others as well (with the same MBean I'm
> trying to get) - see:
> > >
> > > https://github.com/prometheus/jmx_exporter/issues/89
> > >
> > > The person there claims queryNames is broke but queryMBeans is OK -
> that does not work in my example either. Neither query API works.
> > >
> > > I searched JIRA, found nothing related to this MBean not being
> queryable.
> > > _______________________________________________
> > > 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
> > Manager, Senior Principal Software Engineer
> > 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/20171215/f87fec50/attachment.html 

From tomaz.cerar at gmail.com  Fri Dec 15 09:44:55 2017
From: tomaz.cerar at gmail.com (=?utf-8?Q?Toma=C5=BE_Cerar?=)
Date: Fri, 15 Dec 2017 15:44:55 +0100
Subject: [wildfly-dev] Add persistend store to infinispan via CLI fail
In-Reply-To: <1513341440.6192.6.camel@gmail.com>
References: <1513327161.6192.3.camel@gmail.com>
	<5a33a5d9.0587df0a.33936.515c@mx.google.com>
	<1513341440.6192.6.camel@gmail.com>
Message-ID: <5a33dfe3.3786df0a.ccb7e.50c4@mx.google.com>

Yes it should work as well.

Please create issue in Jira https://issues.jboss.org/projects/WFLY
And select ?clustering? and ?domain management? as a component (so it can get properly assigned)

--
tomaz

From: Domenico Briganti
Sent: petek, 15. december 2017 13:37
To: Toma? Cerar; wildfly-dev at lists.jboss.org
Subject: Re: [wildfly-dev] Add persistend store to infinispan via CLI fail

Yes! it work in batch mode. See the attach cli file.

But it should works also in interactive mode, correct?


Domenico


Il giorno ven, 15/12/2017 alle 11.37 +0100, Toma? Cerar ha scritto:
> Does it work if you run you commands in batch?
> ?
> --
> Toma?
> ?
> From: Domenico Briganti
> Sent: petek, 15. december 2017 09:39
> To: wildfly-dev at lists.jboss.org
> Subject: [wildfly-dev] Add persistend store to infinispan via CLI
> fail
> ?file:///opt/wildfly-11.0.0.Final_Bravo/test.cli
> Hi all!
> ?
> I'm trying to configure a persistent file for a local-cache in
> widlfly-11 via CLI but fail, it however works if I put the
> configuration directly on standalone.xml:
> ?
> <local-cache...
> ? <file-store path="authtoken.dat" relative-to="jboss.home.dir"
> passivation="false" preload="true" purge="false"/>
> ?
> I try this CLI command in a fresh wildfly-11 installation, and the
> last
> fail:
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-
> container=reservation:add
> ?
> {"outcome" => "success"}
> ?
> ?
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-
> container=reservation/local-cache=authtoken:add(statistics-
> enabled=true)
> ?
> {"outcome" => "success"}
> ?
> ?
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-
> container=reservation/local-
> cache=authtoken/store=file:add(path=authtoken.dat,relative-
> to=jboss.home.dir,passivation=false,preload=true,purge=true)
> ?
> {
> ????"outcome" => "failed",
> ????"failure-description" => "WFLYCTL0158: Operation handler failed:
> org.jboss.msc.service.DuplicateServiceException: Service
> org.wildfly.clustering.infinispan.cache.store.reservation.authtoken
> is
> already registered",
> ????"rolled-back" => true
> }
> ?
> ?
> Maybe I submit a wrong CLI command?
> ?
> Thanks,
> Domenico Briganti
> ?
> ?
> _______________________________________________
> 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/20171215/3e4d8e86/attachment-0001.html 

From dometec at gmail.com  Fri Dec 15 10:08:08 2017
From: dometec at gmail.com (Domenico Briganti)
Date: Fri, 15 Dec 2017 16:08:08 +0100
Subject: [wildfly-dev] Add persistend store to infinispan via CLI fail
In-Reply-To: <5a33dfe3.3786df0a.ccb7e.50c4@mx.google.com>
References: <1513327161.6192.3.camel@gmail.com>
	<5a33a5d9.0587df0a.33936.515c@mx.google.com>
	<1513341440.6192.6.camel@gmail.com>
	<5a33dfe3.3786df0a.ccb7e.50c4@mx.google.com>
Message-ID: <1513350488.6192.7.camel@gmail.com>

Done, Thanks!

Domenico


Il giorno ven, 15/12/2017 alle 15.44 +0100, Toma? Cerar ha scritto:
> Yes it should work as well.
> ?
> Please create issue in Jira https://issues.jboss.org/projects/WFLY
> And select ?clustering? and ?domain management? as a component (so it
> can get properly assigned)
> ?
> --
> tomaz
> ?
> From: Domenico Briganti
> Sent: petek, 15. december 2017 13:37
> To: Toma? Cerar; wildfly-dev at lists.jboss.org
> Subject: Re: [wildfly-dev] Add persistend store to infinispan via CLI
> fail
> ?
> Yes! it work in batch mode. See the attach cli file.
> ?
> But it should works also in interactive mode, correct?
> ?
> ?
> Domenico
> ?
> ?
> Il giorno ven, 15/12/2017 alle 11.37 +0100, Toma? Cerar ha scritto:
> > Does it work if you run you commands in batch?
> > ?
> > --
> > Toma?
> > ?
> > From: Domenico Briganti
> > Sent: petek, 15. december 2017 09:39
> > To: wildfly-dev at lists.jboss.org
> > Subject: [wildfly-dev] Add persistend store to infinispan via CLI
> > fail
> > ?file:///opt/wildfly-11.0.0.Final_Bravo/test.cli
> > Hi all!
> > ?
> > I'm trying to configure a persistent file for a local-cache in
> > widlfly-11 via CLI but fail, it however works if I put the
> > configuration directly on standalone.xml:
> > ?
> > <local-cache...
> > ? <file-store path="authtoken.dat" relative-to="jboss.home.dir"
> > passivation="false" preload="true" purge="false"/>
> > ?
> > I try this CLI command in a fresh wildfly-11 installation, and the
> > last
> > fail:
> > [standalone at localhost:9990 /] /subsystem=infinispan/cache-
> > container=reservation:add
> > ?
> > {"outcome" => "success"}
> > ?
> > ?
> > [standalone at localhost:9990 /] /subsystem=infinispan/cache-
> > container=reservation/local-cache=authtoken:add(statistics-
> > enabled=true)
> > ?
> > {"outcome" => "success"}
> > ?
> > ?
> > [standalone at localhost:9990 /] /subsystem=infinispan/cache-
> > container=reservation/local-
> > cache=authtoken/store=file:add(path=authtoken.dat,relative-
> > to=jboss.home.dir,passivation=false,preload=true,purge=true)
> > ?
> > {
> > ????"outcome" => "failed",
> > ????"failure-description" => "WFLYCTL0158: Operation handler
> failed:
> > org.jboss.msc.service.DuplicateServiceException: Service
> > org.wildfly.clustering.infinispan.cache.store.reservation.authtoken
> > is
> > already registered",
> > ????"rolled-back" => true
> > }
> > ?
> > ?
> > Maybe I submit a wrong CLI command?
> > ?
> > Thanks,
> > Domenico Briganti
> > ?
> > ?
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > ?
> ?

From jperkins at redhat.com  Fri Dec 15 11:57:11 2017
From: jperkins at redhat.com (James Perkins)
Date: Fri, 15 Dec 2017 08:57:11 -0800
Subject: [wildfly-dev] Logging Changes
In-Reply-To: <CAMw35_q1VCefCMSJtUtoWN1OvF9Oqrh1TPyLqF8YpyjnOWjMXA@mail.gmail.com>
References: <CADGwLpgJGneT61dkb6yBROaHE6avGBSaROOCjqkT9=mv43K0QQ@mail.gmail.com>
	<CAMw35_q1VCefCMSJtUtoWN1OvF9Oqrh1TPyLqF8YpyjnOWjMXA@mail.gmail.com>
Message-ID: <CADGwLpgULzpOiE=Qy+yc=Z4SFYRpy1vdgCNyhTURdDLyTgymdg@mail.gmail.com>

On Thu, Dec 14, 2017 at 7:24 PM, Ken Wills <kwills at redhat.com> wrote:

> I'm not so clear on a lot of the gritty details here, but I would caution
> against any sort of shutdown hook usage. For the embedded use case this is
> a bit of a problem, since they stack up until the user finally quits. There
> is a fairly clear need for an abstraction that executes on some sort of
> "executed unit of work," basis vs actually ends up calling exit().
>

I think we're probably going to have to do some special handling for
embedded. I made some minimal changes to get it working which seems work.
However I did not test with errors that would stop logging from being
fulling configured. Thanks for bringing this up as it will need to be
tested for sure.


>
> Ken
>
> On Thu, Dec 7, 2017 at 3:58 PM James Perkins <jperkins at redhat.com> wrote:
>
>> Hello All,
>> For WildFly 12 (maybe not until 13 at this stage) there are some thoughts
>> on significantly changing the way logging is configured. Currently logging
>> is initialized by reading a logging.properties file when JBoss Modules
>> boots. While this works okay there are a few issues with this approach.
>>
>>
>>    1. For boot logging (before the logging subsystem is initialized) you
>>    can't use property expressions. This means when the logging subsystem
>>    rewrites the logging.properties file with all expressions expanded.
>>    2. Logging objects, such as handlers, cannot use resources from other
>>    subsystems. For example there is a need for a socket-handler. With the
>>    socket handler we need a way to get an SSL context from Elytron. There is
>>    no way for this to be done using a logging.properties file for the boot log
>>    configuration.
>>    3. If the user want to manually change the logging configuration by
>>    editing the XML they also have to edit the logging.properties. If not the
>>    old configuration will be used until the next boot.
>>
>> It would be useful to introduce a way to queue log messages during boot
>> [1]. Once the logging subsystem boot is complete the messages would be
>> drained and sent to the new configuration. This of course isn't without
>> it's own issues.
>>
>>
>>    1. Messages appeared delayed when WildFly is booting. Essentially all
>>    the boot messages are written at once so you see no messages, then all of
>>    them at once.
>>    2. A shutdown hook would have to be used in order to ensure errors
>>    that cause a boot failure are logged.
>>    3. This could get a little tricky with offline CLI as currently
>>    logging is configured based on the logging.properties file
>>    4. If users remove the logging subsystem there are more steps than
>>    just removing logging subsystem to get logging working.
>>    5. There will be a slight performance impact during boot. This can be
>>    greatly reduced if the caller calculation is disabled. This can be done in
>>    normal cases, but we likely can't make it the default. Note too this is
>>    only a boot impact. Once the logging subsystem takes over, the performance
>>    should be exactly the same as it was before.
>>
>> There is some good however too. This does open the door allowing users to
>> more easily replace the log manager implementation for standalone servers.
>> Currently we still, and maybe always will, require the JBoss Log Manager to
>> be used for domain servers, the host controller and process controller.
>>
>> It also removes the need for a logging.properties for servers. I think
>> this is a big bonus to the changes as logging for servers will only be
>> configured in one place now. Domain will be a bit different, but we should
>> likely introduce a logging subsystem on the host controller as well. I just
>> don't think it makes much sense until we can sort out the issues above.
>>
>> The current idea is that boot logging will be configurable via system
>> properties. These properties would have to be set in the JAVA_OPTS.
>>
>> I'm curious to hear any concerns others might have about this. This feels
>> like a rather significant change so I'd rather get it right the first time.
>>
>> I have started a design doc, but it's not finalized yet. If you're
>> curious however you can have at look at it on my topic branch [2]. You can
>> also see some of the small changes I've made to get it working on WildFly
>> Core on that branch.
>>
>>
>> [1]: https://issues.jboss.org/browse/LOGMGR-177
>> [2]: https://github.com/jamezp/wildfly-core/blob/
>> bootstrap-logging/logging/bootstrap-logging.asciidoc
>>
>> --
>> 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
>
>


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

From rory.odonnell at oracle.com  Mon Dec 18 05:24:37 2017
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Mon, 18 Dec 2017 10:24:37 +0000
Subject: [wildfly-dev] JDK 10 entered Rampdown Phase One on 14th of December
Message-ID: <fd22d36c-ecd3-c108-69a9-8a1a0b969982@oracle.com>

Hi Jason/Tomaz,

*JDK 10 entered Rampdown Phase One on Thursday, 14 December [1] *

  * The Rampdown Phase One process will be similar to that of JDK 9 [2].

*JDK 10 Early Access? build 36 is available at : - jdk.java.net/10/*

Notable changes since previous email.

*JEPS included **the last 3 builds:*
JDK-8192833 <https://bugs.openjdk.java.net/browse/JDK-8192833> :This is 
the primary implementation subtask of JEP 322 - *Time-Based Release 
Versioning*
JDK-8189941 <https://bugs.openjdk.java.net/browse/JDK-8189941> : 
Implementation JEP 312: Thread-local handshake
JDK-8186571 <https://bugs.openjdk.java.net/browse/JDK-8186571> : 
Implementation: JEP 307: Parallel Full GC for G1
JDK-8190308 <https://bugs.openjdk.java.net/browse/JDK-8190308> : 
Implementation: JEP 316: Heap Allocation on Alternative Memory Devices

*build 36
*JDK-8148421 <https://bugs.openjdk.java.net/browse/JDK-8148421> : 
Transport Layer Security (TLS) Session Hash and Extended Master Secret 
Extension
JDK-5016517 <https://bugs.openjdk.java.net/browse/JDK-5016517> : Replace 
plaintext passwords by hashed passwords for out-of-the-box JMX Agent

**

*build 35 *
JDK-8188870 <https://bugs.openjdk.java.net/browse/JDK-8188870> - Bump 
classfile version number to 54
JDK-8185985 <http://bugs.openjdk.java.net/browse/JDK-8185985> - HTML 
files in doc-files subdirectories are wrapped with standard javadoc 
decorations
JDK-8186535 <http://bugs.openjdk.java.net/browse/JDK-8186535>*- *Remove 
deprecated pre-1.2 SecurityManager methods and fields

*build 34* - JDK-8024352 
<http://bugs.openjdk.java.net/browse/JDK-8024352> - MBeanOperationInfo 
accepts any int value as "impact"

*Bug fixes reported by Open Source Projects? 
:*<https://bugs.openjdk.java.net/browse/JDK-8191834>
JDK-8191078 <https://bugs.openjdk.java.net/browse/JDK-8191078> : Wrong 
"Package not found" warning
JDK-8191636 <https://bugs.openjdk.java.net/browse/JDK-8191636> : 
[Windows] jshell tool: Wrong character in /env class-path command 
crashes jshell
JDK-8191834 <https://bugs.openjdk.java.net/browse/JDK-8191834> : 
Assigning a void expression to a "var" crashes the 
compiler<https://bugs.openjdk.java.net/browse/JDK-8182638>
JDK-8182638 <https://bugs.openjdk.java.net/browse/JDK-8182638> : 
[macosx] Active modal dialog is hidden by another non-active one
JDK-8043315 <https://bugs.openjdk.java.net/browse/JDK-8043315> : Nimbus: 
Setting Nimbus.Overrides property affects custom keymap installation
JDK-8172244 <https://bugs.openjdk.java.net/browse/JDK-8172244> : AIOOBE 
in KeyStore.getCertificateAlias on Windows
JDK-8180141 <https://bugs.openjdk.java.net/browse/JDK-8180141> : Missing 
entry in LineNumberTable for break statement that jumps out of try-finall

JDK 10 Schedule, Status & Features are available [3]

*Feedback* - If you have suggestions or encounter bugs, please submit 
them using the usual Java SE bug-reporting channel.
Be sure to include complete version information from the output of the 
|java --version| command.

Regards,
Rory

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2017-December/000357.html
[2] http://openjdk.java.net/projects/jdk9/rdp-1
[3] http://openjdk.java.net/projects/jdk/10/

-- 
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/20171218/6cd804a8/attachment-0001.html 

From mmusgrov at redhat.com  Mon Dec 18 09:38:25 2017
From: mmusgrov at redhat.com (Michael Musgrove)
Date: Mon, 18 Dec 2017 14:38:25 +0000
Subject: [wildfly-dev] How to connect to a wildfly port
Message-ID: <CACKZbasZA4hHU-vC9xWBe3mJUG51L-gaz4kSTEu_fG35QVy1Tg@mail.gmail.com>

The wildfly server config contains various socket bindings such as:

<socket-binding name="txn-status-manager" port="4713"/>

When I run netstat -plnt to see which ports wildfly listens on I only see
the http and management port because WildFly is using http upgrade:

tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 163/java
tcp 0 0 0.0.0.0:9990 0.0.0.0:* LISTEN 163/java

Is there a way for me to open the txn-status-manager (port 4713) and write
some data to it.

Mike

-- 
Michael Musgrove
Transactions Team
email: mmusgrov at redhat.com

Our mission:To be the catalyst in communities of customers, contributors,
and partners creating better technology the open source way.

JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale
Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell
Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill,
Keith Phelan, Matt Parson (USA)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171218/217c8d3a/attachment.html 

From tomaz.cerar at gmail.com  Mon Dec 18 10:14:56 2017
From: tomaz.cerar at gmail.com (=?utf-8?Q?Toma=C5=BE_Cerar?=)
Date: Mon, 18 Dec 2017 16:14:56 +0100
Subject: [wildfly-dev] How to connect to a wildfly port
In-Reply-To: <CACKZbasZA4hHU-vC9xWBe3mJUG51L-gaz4kSTEu_fG35QVy1Tg@mail.gmail.com>
References: <CACKZbasZA4hHU-vC9xWBe3mJUG51L-gaz4kSTEu_fG35QVy1Tg@mail.gmail.com>
Message-ID: <5a37db6b.9dae500a.7ba21.d5c9@mx.google.com>

Having socket-bindings defined doesn't mean noting yet.
There must be se subsystem that uses that socket-binding.

Transaction subsystem has reference to this socket binding, so you need to have that configured.

--
tomaz

From: Michael Musgrove
Sent: ponedeljek, 18. december 2017 15:39
To: WildFly Dev
Subject: [wildfly-dev] How to connect to a wildfly port

The wildfly server config contains various socket bindings such as:

<socket-binding name="txn-status-manager" port="4713"/>


When I run netstat -plnt to see which ports wildfly listens on I only see the http and management port because WildFly is using http upgrade:

tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 163/java
tcp 0 0 0.0.0.0:9990 0.0.0.0:* LISTEN 163/java

Is there a way for me to open the?txn-status-manager (port 4713) and write some data to it.

Mike

-- 
Michael Musgrove
Transactions Team
email: mmusgrov at redhat.com

Our mission:To be the catalyst in communities of customers, contributors, and partners creating better technology the open source way.?

JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill, Keith Phelan, Matt Parson (USA)

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

From mmusgrov at redhat.com  Mon Dec 18 10:46:01 2017
From: mmusgrov at redhat.com (Michael Musgrove)
Date: Mon, 18 Dec 2017 15:46:01 +0000
Subject: [wildfly-dev] How to connect to a wildfly port
In-Reply-To: <5a37db6b.9dae500a.7ba21.d5c9@mx.google.com>
References: <CACKZbasZA4hHU-vC9xWBe3mJUG51L-gaz4kSTEu_fG35QVy1Tg@mail.gmail.com>
	<5a37db6b.9dae500a.7ba21.d5c9@mx.google.com>
Message-ID: <CACKZbavYCTFRa4KZ62tP3_vdPW0GnGwrSENWATgcZTa1S2dxnQ@mail.gmail.com>

Yes I have the transaction subsystem configured and running and it should
be using the txn-status-manager socket binding. Are you saying that if our
subsystem has opened the recovery port then it should show up in the
"netstat -plnt" output?

On Mon, Dec 18, 2017 at 3:14 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

> Having socket-bindings defined doesn't mean noting yet.
>
> There must be se subsystem that uses that socket-binding.
>
>
>
> Transaction subsystem has reference to this socket binding, so you need to
> have that configured.
>
>
>
> --
>
> tomaz
>
>
>
> *From: *Michael Musgrove <mmusgrov at redhat.com>
> *Sent: *ponedeljek, 18. december 2017 15:39
> *To: *WildFly Dev <wildfly-dev at lists.jboss.org>
> *Subject: *[wildfly-dev] How to connect to a wildfly port
>
>
>
> The wildfly server config contains various socket bindings such as:
>
>
>
> <socket-binding name="txn-status-manager" port="4713"/>
>
>
>
> When I run netstat -plnt to see which ports wildfly listens on I only see
> the http and management port because WildFly is using http upgrade:
>
>
>
> tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 163/java
>
> tcp 0 0 0.0.0.0:9990 0.0.0.0:* LISTEN 163/java
>
>
>
> Is there a way for me to open the txn-status-manager (port 4713) and write
> some data to it.
>
>
>
> Mike
>
>
>
> --
>
> Michael Musgrove
>
> Transactions Team
>
> email: mmusgrov at redhat.com
>
>
>
> Our mission:To be the catalyst in communities of customers, contributors,
> and partners creating better technology the open source way.
>
>
>
> JBoss, by Red Hat
>
> Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale
> Road, Co. Cork.
>
> Registered in the Companies Registration Office, Parnell House, 14
> Parnell Square, Dublin 1, Ireland, No.304873
> <https://maps.google.com/?q=14+Parnell+Square,+Dublin+1,+Ireland,+No.304873&entry=gmail&source=g>
>
> Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill,
> Keith Phelan, Matt Parson (USA)
>
>
>



-- 
Michael Musgrove
Transactions Team
email: mmusgrov at redhat.com

Our mission:To be the catalyst in communities of customers, contributors,
and partners creating better technology the open source way.

JBoss, by Red Hat
Registered Address: Red Hat Ltd, 6700 Cork Airport Business Park, Kinsale
Road, Co. Cork.
Registered in the Companies Registration Office, Parnell House, 14 Parnell
Square, Dublin 1, Ireland, No.304873
Directors:Michael Cunningham (USA), Vicky Wiseman (USA), Michael O'Neill,
Keith Phelan, Matt Parson (USA)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171218/dac1f1c1/attachment.html 

From rsvoboda at redhat.com  Mon Dec 18 11:20:13 2017
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Mon, 18 Dec 2017 11:20:13 -0500 (EST)
Subject: [wildfly-dev] GRPC subsystem proof of concept
In-Reply-To: <CAFm4XO0gwrRm6+10EiGon674bweXQXbGMiLjBuDcA61C6Xt9Kw@mail.gmail.com>
References: <CAAoo=c5XKAs5=u5shjA=p-puAqu0+HtS14U+f_KjqVVqH1_urg@mail.gmail.com>
	<CAMxVf4PWkB1JJ97mHRYvrYeT8nFj0EaAYa612BJVNSnzAkVdww@mail.gmail.com>
	<CAF1-sp4372jseCi0vDyV4gVTcvCiqjbDvQ1usUy2EP484qa=GA@mail.gmail.com>
	<CAAoo=c40DL9hKa9RxSaASMozFXZ940W5BDk82ajrWDhB65v0qQ@mail.gmail.com>
	<CAFm4XO0gwrRm6+10EiGon674bweXQXbGMiLjBuDcA61C6Xt9Kw@mail.gmail.com>
Message-ID: <1479103011.731866.1513614013474.JavaMail.zimbra@redhat.com>

Hi.

tl;dr: I'm not sure WF is the right place for GRPC integration

1) footprint
  io.grpc: grpc-core grpc-protobuf grpc-stub with deps take 6.1 MB (using version 1.5.0)

2) speed of development
  version 1.5.0 in July
  version 1.8.0 in November
  speed itself is not the main problem, point 3) is more concerning

3) changes in minor releases
I tried mvn clean package -Dgrpc.version=1.8.0 on undertow-grpc and got compilation failure with 18 errors

Every minor (looked at 1.5.0+) has one of the following mentioned in https://github.com/grpc/grpc-java/releases 
  API Changes
  Incompatible Changes
  Behavior changes
  Important Changes

4) cncf.io
Looking at https://www.cncf.io/ my impression is that direct support in OpenShift or SWARM-627 would make sense.

5) yet another integration/rpc solution
We have Corba / EJB, JAX-WS, JAX-RS, JMS.
Do we want / need it grpc in WF? What would be the advantage of this integration?


I know I sound to pessimistic, feel free to turn me into grpc-optimist ;)

Rostislav

----- Original Message -----
> On 12 December 2017 at 22:24, Stuart Douglas <stuart.w.douglas at gmail.com>
> wrote:
> > Not without writing a new protobuf compiler, the compiler does not provide
> > any places to hook into the registration process, the only way I could
> > manage to do it was to subclass the generated class with a proxy. Protobuf
> > generates a fair bit of code for each class anyway, so I don't think the
> > proxy will add much percentage wise.
> 
> The Google tooling for ProtoBuf expect you to use code generation
> depending on the schema, but it's not the only toolset available.
> 
> Infinispan also uses ProtoBuf for encoding of client/server data yet
> forcing people to use code generation seemed too annoying, so they use
> ProtoStream:
>  - https://github.com/infinispan/protostream
> 
> In turn this is based on Square's Protoparser. I have no idea if it's
> more efficient, but it's possible as the alternative feels less
> verbose than the codegeneration approach; it's certainly more
> convenient.
> 
> Hibernate OGM has a "dialect" able to encode JPA storage operations
> into Infinispan Remote calls using a combination of the above
> libraries; in terms of usage people just deploy JPA annotated pojos on
> WildFly and the necessary infrastructure is generated via an internal
> metamodel and a chain of method references: no proxies nor code
> generation.
> 
> Sanne
> 
> >
> > Stuart
> >
> > On Wed, Dec 13, 2017 at 1:30 AM, Andrig Miller <anmiller at redhat.com> wrote:
> >>
> >> Stuart,
> >>
> >>       Because I have memory footprint on the brain, pretty much all the
> >> time now, I wonder if you can change your approach in a way that would
> >> lessen MetaSpace usage.  MetaSpace usage is usually the second largest
> >> memory hog in Wildfly/EAP, and under certain circumstances it can be
> >> larger
> >> than heap, when the right JVM settings are used to control heap usage
> >> (part
> >> of my presentation in 30 minutes).
> >>
> >> Andy
> >>
> >> On Tue, Dec 12, 2017 at 3:48 AM, Darran Lofthouse
> >> <darran.lofthouse at jboss.com> wrote:
> >>>
> >>> On the security question, if we are interested in pursuing this we will
> >>> get an analysis document started to look at the options we have for
> >>> integration with our security implementation.
> >>>
> >>> Regards,
> >>> Darran Lofthouse.
> >>>
> >>>
> >>>
> >>> On Mon, 11 Dec 2017 at 05:17 Stuart Douglas <stuart.w.douglas at gmail.com>
> >>> wrote:
> >>>>
> >>>> Hi everyone,
> >>>>
> >>>> I have done up a proof of concept of GRPC support in Wildfly, which can
> >>>> be found at [1]. GRPC is an RPC protocol designed by Google, that allows
> >>>> for
> >>>> easy cross platform invocations.
> >>>>
> >>>> My proof of concept uses an Undertow based port of GRPC [2] and
> >>>> basically works as follows:
> >>>>
> >>>> - At deployment time Jandex is used to find all non-abstract classes
> >>>> that implement io.grpc.BindableService
> >>>> - I scan the class hierarchy of these classes to find the protobuf
> >>>> generated base class, and create a subclass of this class using
> >>>> ProxyFactory, overriding every method except bindService().
> >>>> - An instance/proxy is created using the ComponentRegistry to do the
> >>>> creation, and the generated proxy delegates all incoming calls to this
> >>>> instance
> >>>> - At runtime any incoming HTTP/2 requests with a type of
> >>>> application/grpc are intercepted, and passed through this newly created
> >>>> proxy.
> >>>>
> >>>> Basically this means that all you need to do as an application developer
> >>>> is define your GRPC endpoints using protobuf, implement the classes
> >>>> generated by the protobuf compiler and then include them in your
> >>>> application, and Wildfly will do the rest. CDI and EJB annotations on
> >>>> your
> >>>> GRPC services should work as normal, for example if you put @Stateless
> >>>> on an
> >>>> endpoint it should work as expected with a SFSB handling all
> >>>> invocations.
> >>>>
> >>>> Note that this is a very early stage POC, and lots of stuff is missing
> >>>> (most notably security).
> >>>>
> >>>> Before I go to much further though I though that I should get some
> >>>> feedback, e.g.
> >>>>
> >>>> - Do we actually want this? I am not sure how much interest there is,
> >>>> but it seems like GRPC could be very useful in a polyglot microservice
> >>>> environment.
> >>>> - Is the current implementation the best way of actually registering
> >>>> GRPC services, or should we require some kind of defining annotation
> >>>> - What security mechanisms should we support? Out of the box standard
> >>>> GRPC is fairly limited
> >>>> - What do we do about transactions? I am leaning towards not supporting
> >>>> them over GRPC, as we already have solutions for Java invocation in the
> >>>> form
> >>>> of our EJB protocol, and I think non-Java clients are unlikely to want
> >>>> to
> >>>> use this.
> >>>>
> >>>> Stuart
> >>>>
> >>>> [1] https://github.com/stuartwdouglas/wildfly/tree/grpc
> >>>> [2] https://github.com/stuartwdouglas/undertow-grpc
> >>>> _______________________________________________
> >>>> 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
> >>
> >>
> >>
> >>
> >> --
> >> Andrig (Andy) T. Miller
> >> Global Platform Director, Middleware
> >> Red Hat, Inc.
> >
> >
> >
> > _______________________________________________
> > 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 stuart.w.douglas at gmail.com  Mon Dec 18 17:53:25 2017
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Tue, 19 Dec 2017 09:53:25 +1100
Subject: [wildfly-dev] GRPC subsystem proof of concept
In-Reply-To: <1479103011.731866.1513614013474.JavaMail.zimbra@redhat.com>
References: <CAAoo=c5XKAs5=u5shjA=p-puAqu0+HtS14U+f_KjqVVqH1_urg@mail.gmail.com>
	<CAMxVf4PWkB1JJ97mHRYvrYeT8nFj0EaAYa612BJVNSnzAkVdww@mail.gmail.com>
	<CAF1-sp4372jseCi0vDyV4gVTcvCiqjbDvQ1usUy2EP484qa=GA@mail.gmail.com>
	<CAAoo=c40DL9hKa9RxSaASMozFXZ940W5BDk82ajrWDhB65v0qQ@mail.gmail.com>
	<CAFm4XO0gwrRm6+10EiGon674bweXQXbGMiLjBuDcA61C6Xt9Kw@mail.gmail.com>
	<1479103011.731866.1513614013474.JavaMail.zimbra@redhat.com>
Message-ID: <CAAoo=c7UOWyeLAm63nckKhq6qpbUuM7uOfzs02V7hr2AVwT4bw@mail.gmail.com>

On Tue, Dec 19, 2017 at 3:20 AM, Rostislav Svoboda <rsvoboda at redhat.com>
wrote:

> Hi.
>
> tl;dr: I'm not sure WF is the right place for GRPC integration
>
> 1) footprint
>   io.grpc: grpc-core grpc-protobuf grpc-stub with deps take 6.1 MB (using
> version 1.5.0)
>

Not much we can do about that, but it won't be loaded unless you are using
it.


>
> 2) speed of development
>   version 1.5.0 in July
>   version 1.8.0 in November
>   speed itself is not the main problem, point 3) is more concerning
>
> 3) changes in minor releases
> I tried mvn clean package -Dgrpc.version=1.8.0 on undertow-grpc and got
> compilation failure with 18 errors
>

Yea, that is somewhat annoying. I don't think it affects the wire protocol
though, just the Java SPI (even though they provide an integration SPI I
don't think anyone has really tried to use it before, and provide a
transport outside what is already provided in the distribution).


>
> Every minor (looked at 1.5.0+) has one of the following mentioned in
> https://github.com/grpc/grpc-java/releases
>   API Changes
>   Incompatible Changes
>   Behavior changes
>   Important Changes
>
> 4) cncf.io
> Looking at https://www.cncf.io/ my impression is that direct support in
> OpenShift or SWARM-627 would make sense.
>

I think that once we have a provisioning solution there is no reason why we
can't provide things like this to work in both swarm and WildFly.


>
> 5) yet another integration/rpc solution
> We have Corba / EJB, JAX-WS, JAX-RS, JMS.
> Do we want / need it grpc in WF? What would be the advantage of this
> integration?
>

The main advantage is that it is a binary cross platform solution that
provides strong typing (JAX-RS/REST is also cross platform, but generally
you don't get the same strong typing guarantees and it is more verbose on
the wire).


>
> I know I sound to pessimistic, feel free to turn me into grpc-optimist ;)
>

Fair enough. I posted this to try and gauge interest to see if this is
worth pursuing, we can't do everything so unless there is interest it
probably won't go past the proof of concept stage.

Stuart


>
> Rostislav
>
> ----- Original Message -----
> > On 12 December 2017 at 22:24, Stuart Douglas <stuart.w.douglas at gmail.com
> >
> > wrote:
> > > Not without writing a new protobuf compiler, the compiler does not
> provide
> > > any places to hook into the registration process, the only way I could
> > > manage to do it was to subclass the generated class with a proxy.
> Protobuf
> > > generates a fair bit of code for each class anyway, so I don't think
> the
> > > proxy will add much percentage wise.
> >
> > The Google tooling for ProtoBuf expect you to use code generation
> > depending on the schema, but it's not the only toolset available.
> >
> > Infinispan also uses ProtoBuf for encoding of client/server data yet
> > forcing people to use code generation seemed too annoying, so they use
> > ProtoStream:
> >  - https://github.com/infinispan/protostream
> >
> > In turn this is based on Square's Protoparser. I have no idea if it's
> > more efficient, but it's possible as the alternative feels less
> > verbose than the codegeneration approach; it's certainly more
> > convenient.
> >
> > Hibernate OGM has a "dialect" able to encode JPA storage operations
> > into Infinispan Remote calls using a combination of the above
> > libraries; in terms of usage people just deploy JPA annotated pojos on
> > WildFly and the necessary infrastructure is generated via an internal
> > metamodel and a chain of method references: no proxies nor code
> > generation.
> >
> > Sanne
> >
> > >
> > > Stuart
> > >
> > > On Wed, Dec 13, 2017 at 1:30 AM, Andrig Miller <anmiller at redhat.com>
> wrote:
> > >>
> > >> Stuart,
> > >>
> > >>       Because I have memory footprint on the brain, pretty much all
> the
> > >> time now, I wonder if you can change your approach in a way that would
> > >> lessen MetaSpace usage.  MetaSpace usage is usually the second largest
> > >> memory hog in Wildfly/EAP, and under certain circumstances it can be
> > >> larger
> > >> than heap, when the right JVM settings are used to control heap usage
> > >> (part
> > >> of my presentation in 30 minutes).
> > >>
> > >> Andy
> > >>
> > >> On Tue, Dec 12, 2017 at 3:48 AM, Darran Lofthouse
> > >> <darran.lofthouse at jboss.com> wrote:
> > >>>
> > >>> On the security question, if we are interested in pursuing this we
> will
> > >>> get an analysis document started to look at the options we have for
> > >>> integration with our security implementation.
> > >>>
> > >>> Regards,
> > >>> Darran Lofthouse.
> > >>>
> > >>>
> > >>>
> > >>> On Mon, 11 Dec 2017 at 05:17 Stuart Douglas <
> stuart.w.douglas at gmail.com>
> > >>> wrote:
> > >>>>
> > >>>> Hi everyone,
> > >>>>
> > >>>> I have done up a proof of concept of GRPC support in Wildfly, which
> can
> > >>>> be found at [1]. GRPC is an RPC protocol designed by Google, that
> allows
> > >>>> for
> > >>>> easy cross platform invocations.
> > >>>>
> > >>>> My proof of concept uses an Undertow based port of GRPC [2] and
> > >>>> basically works as follows:
> > >>>>
> > >>>> - At deployment time Jandex is used to find all non-abstract classes
> > >>>> that implement io.grpc.BindableService
> > >>>> - I scan the class hierarchy of these classes to find the protobuf
> > >>>> generated base class, and create a subclass of this class using
> > >>>> ProxyFactory, overriding every method except bindService().
> > >>>> - An instance/proxy is created using the ComponentRegistry to do the
> > >>>> creation, and the generated proxy delegates all incoming calls to
> this
> > >>>> instance
> > >>>> - At runtime any incoming HTTP/2 requests with a type of
> > >>>> application/grpc are intercepted, and passed through this newly
> created
> > >>>> proxy.
> > >>>>
> > >>>> Basically this means that all you need to do as an application
> developer
> > >>>> is define your GRPC endpoints using protobuf, implement the classes
> > >>>> generated by the protobuf compiler and then include them in your
> > >>>> application, and Wildfly will do the rest. CDI and EJB annotations
> on
> > >>>> your
> > >>>> GRPC services should work as normal, for example if you put
> @Stateless
> > >>>> on an
> > >>>> endpoint it should work as expected with a SFSB handling all
> > >>>> invocations.
> > >>>>
> > >>>> Note that this is a very early stage POC, and lots of stuff is
> missing
> > >>>> (most notably security).
> > >>>>
> > >>>> Before I go to much further though I though that I should get some
> > >>>> feedback, e.g.
> > >>>>
> > >>>> - Do we actually want this? I am not sure how much interest there
> is,
> > >>>> but it seems like GRPC could be very useful in a polyglot
> microservice
> > >>>> environment.
> > >>>> - Is the current implementation the best way of actually registering
> > >>>> GRPC services, or should we require some kind of defining annotation
> > >>>> - What security mechanisms should we support? Out of the box
> standard
> > >>>> GRPC is fairly limited
> > >>>> - What do we do about transactions? I am leaning towards not
> supporting
> > >>>> them over GRPC, as we already have solutions for Java invocation in
> the
> > >>>> form
> > >>>> of our EJB protocol, and I think non-Java clients are unlikely to
> want
> > >>>> to
> > >>>> use this.
> > >>>>
> > >>>> Stuart
> > >>>>
> > >>>> [1] https://github.com/stuartwdouglas/wildfly/tree/grpc
> > >>>> [2] https://github.com/stuartwdouglas/undertow-grpc
> > >>>> _______________________________________________
> > >>>> 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
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Andrig (Andy) T. Miller
> > >> Global Platform Director, Middleware
> > >> Red Hat, Inc.
> > >
> > >
> > >
> > > _______________________________________________
> > > 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/20171219/0ca3dd28/attachment.html 

From jason.greene at redhat.com  Mon Dec 18 18:12:27 2017
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 18 Dec 2017 17:12:27 -0600
Subject: [wildfly-dev] GRPC subsystem proof of concept
In-Reply-To: <CAAoo=c7UOWyeLAm63nckKhq6qpbUuM7uOfzs02V7hr2AVwT4bw@mail.gmail.com>
References: <CAAoo=c5XKAs5=u5shjA=p-puAqu0+HtS14U+f_KjqVVqH1_urg@mail.gmail.com>
	<CAMxVf4PWkB1JJ97mHRYvrYeT8nFj0EaAYa612BJVNSnzAkVdww@mail.gmail.com>
	<CAF1-sp4372jseCi0vDyV4gVTcvCiqjbDvQ1usUy2EP484qa=GA@mail.gmail.com>
	<CAAoo=c40DL9hKa9RxSaASMozFXZ940W5BDk82ajrWDhB65v0qQ@mail.gmail.com>
	<CAFm4XO0gwrRm6+10EiGon674bweXQXbGMiLjBuDcA61C6Xt9Kw@mail.gmail.com>
	<1479103011.731866.1513614013474.JavaMail.zimbra@redhat.com>
	<CAAoo=c7UOWyeLAm63nckKhq6qpbUuM7uOfzs02V7hr2AVwT4bw@mail.gmail.com>
Message-ID: <7ED6151F-FE83-472B-85E8-FEB5E8E36211@redhat.com>


> On Dec 18, 2017, at 4:53 PM, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:
> 
> 
> 
> On Tue, Dec 19, 2017 at 3:20 AM, Rostislav Svoboda <rsvoboda at redhat.com <mailto:rsvoboda at redhat.com>> wrote:
> Hi.
> 
> tl;dr: I'm not sure WF is the right place for GRPC integration
> 
> 1) footprint
>   io.grpc: grpc-core grpc-protobuf grpc-stub with deps take 6.1 MB (using version 1.5.0)
> 
> Not much we can do about that, but it won?t be loaded unless you are using it.

Also once we have provisioning then it could be easily removed and/or kept as an optional feature.
>  
> 
> 2) speed of development
>   version 1.5.0 in July
>   version 1.8.0 in November
>   speed itself is not the main problem, point 3) is more concerning
> 
> 3) changes in minor releases
> I tried mvn clean package -Dgrpc.version=1.8.0 on undertow-grpc and got compilation failure with 18 errors
> 
> Yea, that is somewhat annoying. I don?t think it affects the wire protocol though, just the Java SPI (even though they provide an integration SPI I don't think anyone has really tried to use it before, and provide a transport outside what is already provided in the distribution).

Even with the SPI  it looks fairly reasonable: going through the history it appears they deprecate stuff first, then many releases later remove the deprecated methods. Of course I might have missed something.

-Jason


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

From jason.greene at redhat.com  Mon Dec 18 18:12:27 2017
From: jason.greene at redhat.com (Jason Greene)
Date: Mon, 18 Dec 2017 17:12:27 -0600
Subject: [wildfly-dev] GRPC subsystem proof of concept
In-Reply-To: <CAAoo=c7UOWyeLAm63nckKhq6qpbUuM7uOfzs02V7hr2AVwT4bw@mail.gmail.com>
References: <CAAoo=c5XKAs5=u5shjA=p-puAqu0+HtS14U+f_KjqVVqH1_urg@mail.gmail.com>
	<CAMxVf4PWkB1JJ97mHRYvrYeT8nFj0EaAYa612BJVNSnzAkVdww@mail.gmail.com>
	<CAF1-sp4372jseCi0vDyV4gVTcvCiqjbDvQ1usUy2EP484qa=GA@mail.gmail.com>
	<CAAoo=c40DL9hKa9RxSaASMozFXZ940W5BDk82ajrWDhB65v0qQ@mail.gmail.com>
	<CAFm4XO0gwrRm6+10EiGon674bweXQXbGMiLjBuDcA61C6Xt9Kw@mail.gmail.com>
	<1479103011.731866.1513614013474.JavaMail.zimbra@redhat.com>
	<CAAoo=c7UOWyeLAm63nckKhq6qpbUuM7uOfzs02V7hr2AVwT4bw@mail.gmail.com>
Message-ID: <1B2D231F-2C3C-490D-8CEE-CBB23B0F6794@redhat.com>


> On Dec 18, 2017, at 4:53 PM, Stuart Douglas <stuart.w.douglas at gmail.com <mailto:stuart.w.douglas at gmail.com>> wrote:
> 
> 
> 
> On Tue, Dec 19, 2017 at 3:20 AM, Rostislav Svoboda <rsvoboda at redhat.com <mailto:rsvoboda at redhat.com>> wrote:
> Hi.
> 
> tl;dr: I'm not sure WF is the right place for GRPC integration
> 
> 1) footprint
>   io.grpc: grpc-core grpc-protobuf grpc-stub with deps take 6.1 MB (using version 1.5.0)
> 
> Not much we can do about that, but it won?t be loaded unless you are using it.

Also once we have provisioning then it could be easily removed and/or kept as an optional feature.
>  
> 
> 2) speed of development
>   version 1.5.0 in July
>   version 1.8.0 in November
>   speed itself is not the main problem, point 3) is more concerning
> 
> 3) changes in minor releases
> I tried mvn clean package -Dgrpc.version=1.8.0 on undertow-grpc and got compilation failure with 18 errors
> 
> Yea, that is somewhat annoying. I don?t think it affects the wire protocol though, just the Java SPI (even though they provide an integration SPI I don't think anyone has really tried to use it before, and provide a transport outside what is already provided in the distribution).

Even with the SPI  it looks fairly reasonable: going through the history it appears they deprecate stuff first, then many releases later remove the deprecated methods. Of course I might have missed something.

-Jason


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

From rsvoboda at redhat.com  Tue Dec 19 03:16:49 2017
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Tue, 19 Dec 2017 03:16:49 -0500 (EST)
Subject: [wildfly-dev] GRPC subsystem proof of concept
In-Reply-To: <1B2D231F-2C3C-490D-8CEE-CBB23B0F6794@redhat.com>
References: <CAAoo=c5XKAs5=u5shjA=p-puAqu0+HtS14U+f_KjqVVqH1_urg@mail.gmail.com>
	<CAMxVf4PWkB1JJ97mHRYvrYeT8nFj0EaAYa612BJVNSnzAkVdww@mail.gmail.com>
	<CAF1-sp4372jseCi0vDyV4gVTcvCiqjbDvQ1usUy2EP484qa=GA@mail.gmail.com>
	<CAAoo=c40DL9hKa9RxSaASMozFXZ940W5BDk82ajrWDhB65v0qQ@mail.gmail.com>
	<CAFm4XO0gwrRm6+10EiGon674bweXQXbGMiLjBuDcA61C6Xt9Kw@mail.gmail.com>
	<1479103011.731866.1513614013474.JavaMail.zimbra@redhat.com>
	<CAAoo=c7UOWyeLAm63nckKhq6qpbUuM7uOfzs02V7hr2AVwT4bw@mail.gmail.com>
	<1B2D231F-2C3C-490D-8CEE-CBB23B0F6794@redhat.com>
Message-ID: <895959571.998765.1513671409466.JavaMail.zimbra@redhat.com>


> > 1) footprint
> >   io.grpc: grpc-core grpc-protobuf grpc-stub with deps take 6.1 MB (using
> >   version 1.5.0)
> > 
> > Not much we can do about that, but it won?t be loaded unless you are using
> > it.
> 
> Also once we have provisioning then it could be easily removed and/or kept as
> an optional feature.

Side note to provisioning:
  We could have some kind of EPEL repository to indicate that feature packs available there are optional / evolving_quickly / kind_of_PoC



From ebenzacar at gmail.com  Tue Dec 19 11:38:39 2017
From: ebenzacar at gmail.com (Eric B)
Date: Tue, 19 Dec 2017 11:38:39 -0500
Subject: [wildfly-dev] How to configure Wildfly to use the
	InMemorySessionManager instead of DistributableSessionManager?
Message-ID: <CA+T+PjE445pHrDiw999-TO9kXdTtQ-4Jdg4mbt=2tVyQ=XCFCg@mail.gmail.com>

Further to a previous post for session problems in my application, I
believe some of my issues relate to the DistributableSessions that are
being used by Wildfly.  However, in my configuration file, I have my web
cache defined as a local cache:



        <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
            <cache-container name="server" aliases="singleton cluster"
default-cache="default" module="org.wildfly.clustering.server">
                <transport lock-timeout="60000"/>
                <replicated-cache name="default" mode="SYNC">
                    <transaction mode="BATCH"/>
                </replicated-cache>
            </cache-container>
            <cache-container name="web" default-cache="passivation"
module="org.wildfly.clustering.web.infinispan">
                <local-cache name="passivation">
                    <locking isolation="REPEATABLE_READ"/>
                    <transaction mode="BATCH"/>
                    <file-store passivation="true" purge="false"/>
                </local-cache>
                <local-cache name="persistent">
                    <locking isolation="REPEATABLE_READ"/>
                    <transaction mode="BATCH"/>
                    <file-store passivation="false" purge="false"/>
                </local-cache>
            </cache-container>
...
...


I see that undertow comes with an InMemorySessionManager, but not entirely
sure how to enable it.  Do I have to go through the effort of creating my
own ServletExtension and configuring it in the
META-INF/services/io.undertow.servlet.ServletExtension or is there an
out-of-the-box way of enable functionality that already exists via the
config file?

Thanks,

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171219/6469196e/attachment.html 

From ebenzacar at gmail.com  Tue Dec 19 12:29:33 2017
From: ebenzacar at gmail.com (Eric B)
Date: Tue, 19 Dec 2017 12:29:33 -0500
Subject: [wildfly-dev] How to configure Wildfly to use the
 InMemorySessionManager instead of DistributableSessionManager?
In-Reply-To: <CA+T+PjE445pHrDiw999-TO9kXdTtQ-4Jdg4mbt=2tVyQ=XCFCg@mail.gmail.com>
References: <CA+T+PjE445pHrDiw999-TO9kXdTtQ-4Jdg4mbt=2tVyQ=XCFCg@mail.gmail.com>
Message-ID: <CA+T+PjEN5Pb77cNs3Vc0SQeq1ZQUog5ZQfs1HJoWZSQ3O3x+Hw@mail.gmail.com>

I've continued digging into my issue and noticed that the default
DistributableSessionManager uses
the org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager,
which I guess comes from the module parameter in the cache-container
definition.

Part of my problem is that I am trying to invalidate() the session returned
by the SessionManager, but when I do a
SessionManager.getSession(sessionId), it returns an
DistributableImmutableSession whose invalidate() method intentionally does
nothing.

So how can I invalidate a session?  Is there no way to invalidate a session
by sessionId with the DistributableSessionManager?  If so, how?  If not,
how do I define a SessionManager that would give me access that?

Thanks,

Eric

On Tue, Dec 19, 2017 at 11:38 AM, Eric B <ebenzacar at gmail.com> wrote:

> Further to a previous post for session problems in my application, I
> believe some of my issues relate to the DistributableSessions that are
> being used by Wildfly.  However, in my configuration file, I have my web
> cache defined as a local cache:
>
>
>
>         <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
>             <cache-container name="server" aliases="singleton cluster"
> default-cache="default" module="org.wildfly.clustering.server">
>                 <transport lock-timeout="60000"/>
>                 <replicated-cache name="default" mode="SYNC">
>                     <transaction mode="BATCH"/>
>                 </replicated-cache>
>             </cache-container>
>             <cache-container name="web" default-cache="passivation"
> module="org.wildfly.clustering.web.infinispan">
>                 <local-cache name="passivation">
>                     <locking isolation="REPEATABLE_READ"/>
>                     <transaction mode="BATCH"/>
>                     <file-store passivation="true" purge="false"/>
>                 </local-cache>
>                 <local-cache name="persistent">
>                     <locking isolation="REPEATABLE_READ"/>
>                     <transaction mode="BATCH"/>
>                     <file-store passivation="false" purge="false"/>
>                 </local-cache>
>             </cache-container>
> ...
> ...
>
>
> I see that undertow comes with an InMemorySessionManager, but not entirely
> sure how to enable it.  Do I have to go through the effort of creating my
> own ServletExtension and configuring it in the
> META-INF/services/io.undertow.servlet.ServletExtension or is there an
> out-of-the-box way of enable functionality that already exists via the
> config file?
>
> Thanks,
>
> Eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20171219/4aed9898/attachment.html 

From stuart.w.douglas at gmail.com  Tue Dec 19 17:44:25 2017
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 20 Dec 2017 09:44:25 +1100
Subject: [wildfly-dev] How to configure Wildfly to use the
 InMemorySessionManager instead of DistributableSessionManager?
In-Reply-To: <CA+T+PjEN5Pb77cNs3Vc0SQeq1ZQUog5ZQfs1HJoWZSQ3O3x+Hw@mail.gmail.com>
References: <CA+T+PjE445pHrDiw999-TO9kXdTtQ-4Jdg4mbt=2tVyQ=XCFCg@mail.gmail.com>
	<CA+T+PjEN5Pb77cNs3Vc0SQeq1ZQUog5ZQfs1HJoWZSQ3O3x+Hw@mail.gmail.com>
Message-ID: <CAAoo=c7yO9AhVTokqT2MCMnzHAzsuKMWyPsnSFNiuVid7zD2Pw@mail.gmail.com>

If you remove <distributable/> from your web.xml you should just get the
InMemorySessionManager.

Stuart

On Wed, Dec 20, 2017 at 4:29 AM, Eric B <ebenzacar at gmail.com> wrote:

> I've continued digging into my issue and noticed that the default
> DistributableSessionManager uses the org.wildfly.clustering.
> web.infinispan.session.InfinispanSessionManager, which I guess comes from
> the module parameter in the cache-container definition.
>
> Part of my problem is that I am trying to invalidate() the session
> returned by the SessionManager, but when I do a SessionManager.getSession(sessionId),
> it returns an DistributableImmutableSession whose invalidate() method
> intentionally does nothing.
>
> So how can I invalidate a session?  Is there no way to invalidate a
> session by sessionId with the DistributableSessionManager?  If so, how?  If
> not, how do I define a SessionManager that would give me access that?
>
> Thanks,
>
> Eric
>
> On Tue, Dec 19, 2017 at 11:38 AM, Eric B <ebenzacar at gmail.com> wrote:
>
>> Further to a previous post for session problems in my application, I
>> believe some of my issues relate to the DistributableSessions that are
>> being used by Wildfly.  However, in my configuration file, I have my web
>> cache defined as a local cache:
>>
>>
>>
>>         <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
>>             <cache-container name="server" aliases="singleton cluster"
>> default-cache="default" module="org.wildfly.clustering.server">
>>                 <transport lock-timeout="60000"/>
>>                 <replicated-cache name="default" mode="SYNC">
>>                     <transaction mode="BATCH"/>
>>                 </replicated-cache>
>>             </cache-container>
>>             <cache-container name="web" default-cache="passivation"
>> module="org.wildfly.clustering.web.infinispan">
>>                 <local-cache name="passivation">
>>                     <locking isolation="REPEATABLE_READ"/>
>>                     <transaction mode="BATCH"/>
>>                     <file-store passivation="true" purge="false"/>
>>                 </local-cache>
>>                 <local-cache name="persistent">
>>                     <locking isolation="REPEATABLE_READ"/>
>>                     <transaction mode="BATCH"/>
>>                     <file-store passivation="false" purge="false"/>
>>                 </local-cache>
>>             </cache-container>
>> ...
>> ...
>>
>>
>> I see that undertow comes with an InMemorySessionManager, but not
>> entirely sure how to enable it.  Do I have to go through the effort of
>> creating my own ServletExtension and configuring it in the
>> META-INF/services/io.undertow.servlet.ServletExtension or is there an
>> out-of-the-box way of enable functionality that already exists via the
>> config file?
>>
>> Thanks,
>>
>> Eric
>>
>
>
> _______________________________________________
> 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/20171220/d1dcc440/attachment-0001.html 

From ebenzacar at gmail.com  Wed Dec 20 00:49:41 2017
From: ebenzacar at gmail.com (Eric B)
Date: Wed, 20 Dec 2017 00:49:41 -0500
Subject: [wildfly-dev] How to configure Wildfly to use the
 InMemorySessionManager instead of DistributableSessionManager?
In-Reply-To: <CAAoo=c7yO9AhVTokqT2MCMnzHAzsuKMWyPsnSFNiuVid7zD2Pw@mail.gmail.com>
References: <CA+T+PjE445pHrDiw999-TO9kXdTtQ-4Jdg4mbt=2tVyQ=XCFCg@mail.gmail.com>
	<CA+T+PjEN5Pb77cNs3Vc0SQeq1ZQUog5ZQfs1HJoWZSQ3O3x+Hw@mail.gmail.com>
	<CAAoo=c7yO9AhVTokqT2MCMnzHAzsuKMWyPsnSFNiuVid7zD2Pw@mail.gmail.com>
Message-ID: <CA+T+PjGgmUn+bQGA3kkKfzKm7TPGQiddU1o1i2S_2qrN=9_UXQ@mail.gmail.com>

Hi Stuart,

Strangely enough, my web.xml does not have distributable defined.

I managed to get the InMemorySessionManager working by using a servlet
extension, but I can't help but think I'm using a sledge hammer to
configure it that way.  I can't believe there isn't another way to enable
non distributable sessions.

My application is a JEE ear with 2 web apps (using a shared session cookie)
and an EJB package if that makes a difference.

Thanks

Eric


On Dec 19, 2017 5:44 PM, "Stuart Douglas" <stuart.w.douglas at gmail.com>
wrote:

If you remove <distributable/> from your web.xml you should just get the
InMemorySessionManager.

Stuart

On Wed, Dec 20, 2017 at 4:29 AM, Eric B <ebenzacar at gmail.com> wrote:

> I've continued digging into my issue and noticed that the default
> DistributableSessionManager uses the org.wildfly.clustering.web
> .infinispan.session.InfinispanSessionManager, which I guess comes from
> the module parameter in the cache-container definition.
>
> Part of my problem is that I am trying to invalidate() the session
> returned by the SessionManager, but when I do a
> SessionManager.getSession(sessionId), it returns an
> DistributableImmutableSession whose invalidate() method intentionally does
> nothing.
>
> So how can I invalidate a session?  Is there no way to invalidate a
> session by sessionId with the DistributableSessionManager?  If so, how?  If
> not, how do I define a SessionManager that would give me access that?
>
> Thanks,
>
> Eric
>
> On Tue, Dec 19, 2017 at 11:38 AM, Eric B <ebenzacar at gmail.com> wrote:
>
>> Further to a previous post for session problems in my application, I
>> believe some of my issues relate to the DistributableSessions that are
>> being used by Wildfly.  However, in my configuration file, I have my web
>> cache defined as a local cache:
>>
>>
>>
>>         <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
>>             <cache-container name="server" aliases="singleton cluster"
>> default-cache="default" module="org.wildfly.clustering.server">
>>                 <transport lock-timeout="60000"/>
>>                 <replicated-cache name="default" mode="SYNC">
>>                     <transaction mode="BATCH"/>
>>                 </replicated-cache>
>>             </cache-container>
>>             <cache-container name="web" default-cache="passivation"
>> module="org.wildfly.clustering.web.infinispan">
>>                 <local-cache name="passivation">
>>                     <locking isolation="REPEATABLE_READ"/>
>>                     <transaction mode="BATCH"/>
>>                     <file-store passivation="true" purge="false"/>
>>                 </local-cache>
>>                 <local-cache name="persistent">
>>                     <locking isolation="REPEATABLE_READ"/>
>>                     <transaction mode="BATCH"/>
>>                     <file-store passivation="false" purge="false"/>
>>                 </local-cache>
>>             </cache-container>
>> ...
>> ...
>>
>>
>> I see that undertow comes with an InMemorySessionManager, but not
>> entirely sure how to enable it.  Do I have to go through the effort of
>> creating my own ServletExtension and configuring it in the
>> META-INF/services/io.undertow.servlet.ServletExtension or is there an
>> out-of-the-box way of enable functionality that already exists via the
>> config file?
>>
>> Thanks,
>>
>> Eric
>>
>
>
> _______________________________________________
> 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/20171220/4784bd80/attachment.html 

From stuart.w.douglas at gmail.com  Wed Dec 20 01:10:36 2017
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Wed, 20 Dec 2017 17:10:36 +1100
Subject: [wildfly-dev] How to configure Wildfly to use the
 InMemorySessionManager instead of DistributableSessionManager?
In-Reply-To: <CA+T+PjGgmUn+bQGA3kkKfzKm7TPGQiddU1o1i2S_2qrN=9_UXQ@mail.gmail.com>
References: <CA+T+PjE445pHrDiw999-TO9kXdTtQ-4Jdg4mbt=2tVyQ=XCFCg@mail.gmail.com>
	<CA+T+PjEN5Pb77cNs3Vc0SQeq1ZQUog5ZQfs1HJoWZSQ3O3x+Hw@mail.gmail.com>
	<CAAoo=c7yO9AhVTokqT2MCMnzHAzsuKMWyPsnSFNiuVid7zD2Pw@mail.gmail.com>
	<CA+T+PjGgmUn+bQGA3kkKfzKm7TPGQiddU1o1i2S_2qrN=9_UXQ@mail.gmail.com>
Message-ID: <CAAoo=c5BoCfAQgRNPtQy6X2FpGvBfJHGGn1GMEWvT=JdawJdxA@mail.gmail.com>

Are you using the shared session functionality? Or just overriding the
cookie path so the same cookie is used for two different session managers?

Stuart

On Wed, Dec 20, 2017 at 4:49 PM, Eric B <ebenzacar at gmail.com> wrote:

> Hi Stuart,
>
> Strangely enough, my web.xml does not have distributable defined.
>
> I managed to get the InMemorySessionManager working by using a servlet
> extension, but I can't help but think I'm using a sledge hammer to
> configure it that way.  I can't believe there isn't another way to enable
> non distributable sessions.
>
> My application is a JEE ear with 2 web apps (using a shared session
> cookie) and an EJB package if that makes a difference.
>
> Thanks
>
> Eric
>
>
> On Dec 19, 2017 5:44 PM, "Stuart Douglas" <stuart.w.douglas at gmail.com>
> wrote:
>
> If you remove <distributable/> from your web.xml you should just get the
> InMemorySessionManager.
>
> Stuart
>
> On Wed, Dec 20, 2017 at 4:29 AM, Eric B <ebenzacar at gmail.com> wrote:
>
>> I've continued digging into my issue and noticed that the default
>> DistributableSessionManager uses the org.wildfly.clustering.web
>> .infinispan.session.InfinispanSessionManager, which I guess comes from
>> the module parameter in the cache-container definition.
>>
>> Part of my problem is that I am trying to invalidate() the session
>> returned by the SessionManager, but when I do a
>> SessionManager.getSession(sessionId), it returns an
>> DistributableImmutableSession whose invalidate() method intentionally does
>> nothing.
>>
>> So how can I invalidate a session?  Is there no way to invalidate a
>> session by sessionId with the DistributableSessionManager?  If so, how?  If
>> not, how do I define a SessionManager that would give me access that?
>>
>> Thanks,
>>
>> Eric
>>
>> On Tue, Dec 19, 2017 at 11:38 AM, Eric B <ebenzacar at gmail.com> wrote:
>>
>>> Further to a previous post for session problems in my application, I
>>> believe some of my issues relate to the DistributableSessions that are
>>> being used by Wildfly.  However, in my configuration file, I have my web
>>> cache defined as a local cache:
>>>
>>>
>>>
>>>         <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
>>>             <cache-container name="server" aliases="singleton cluster"
>>> default-cache="default" module="org.wildfly.clustering.server">
>>>                 <transport lock-timeout="60000"/>
>>>                 <replicated-cache name="default" mode="SYNC">
>>>                     <transaction mode="BATCH"/>
>>>                 </replicated-cache>
>>>             </cache-container>
>>>             <cache-container name="web" default-cache="passivation"
>>> module="org.wildfly.clustering.web.infinispan">
>>>                 <local-cache name="passivation">
>>>                     <locking isolation="REPEATABLE_READ"/>
>>>                     <transaction mode="BATCH"/>
>>>                     <file-store passivation="true" purge="false"/>
>>>                 </local-cache>
>>>                 <local-cache name="persistent">
>>>                     <locking isolation="REPEATABLE_READ"/>
>>>                     <transaction mode="BATCH"/>
>>>                     <file-store passivation="false" purge="false"/>
>>>                 </local-cache>
>>>             </cache-container>
>>> ...
>>> ...
>>>
>>>
>>> I see that undertow comes with an InMemorySessionManager, but not
>>> entirely sure how to enable it.  Do I have to go through the effort of
>>> creating my own ServletExtension and configuring it in the
>>> META-INF/services/io.undertow.servlet.ServletExtension or is there an
>>> out-of-the-box way of enable functionality that already exists via the
>>> config file?
>>>
>>> Thanks,
>>>
>>> Eric
>>>
>>
>>
>> _______________________________________________
>> 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/20171220/f8562452/attachment.html 

From ebenzacar at gmail.com  Wed Dec 20 07:07:04 2017
From: ebenzacar at gmail.com (Eric B)
Date: Wed, 20 Dec 2017 07:07:04 -0500
Subject: [wildfly-dev] How to configure Wildfly to use the
 InMemorySessionManager instead of DistributableSessionManager?
In-Reply-To: <CAAoo=c5BoCfAQgRNPtQy6X2FpGvBfJHGGn1GMEWvT=JdawJdxA@mail.gmail.com>
References: <CA+T+PjE445pHrDiw999-TO9kXdTtQ-4Jdg4mbt=2tVyQ=XCFCg@mail.gmail.com>
	<CA+T+PjEN5Pb77cNs3Vc0SQeq1ZQUog5ZQfs1HJoWZSQ3O3x+Hw@mail.gmail.com>
	<CAAoo=c7yO9AhVTokqT2MCMnzHAzsuKMWyPsnSFNiuVid7zD2Pw@mail.gmail.com>
	<CA+T+PjGgmUn+bQGA3kkKfzKm7TPGQiddU1o1i2S_2qrN=9_UXQ@mail.gmail.com>
	<CAAoo=c5BoCfAQgRNPtQy6X2FpGvBfJHGGn1GMEWvT=JdawJdxA@mail.gmail.com>
Message-ID: <CA+T+PjG10PETh8tDhZWJccry4YzJyw++bO2jUB-VceM6j_wwkA@mail.gmail.com>

I've changed the cookie path to / within the jboss-all.xml file in order
for two war to share the same session.  (Each war has its own context path:
/war1, /war).  I essentially need one war to be able to authenticate and
authorize the user, and have that authentication/authorization carry over
to the session in the other war.  I don't actually need to share the
session other than for auth purposes.

Is that feasible using the InMemorySessionManager?  Is there a way to
ensure that they are all using the same InMemorySessionManager?

Thanks

Eric

On Dec 20, 2017 1:10 AM, "Stuart Douglas" <stuart.w.douglas at gmail.com>
wrote:

> Are you using the shared session functionality? Or just overriding the
> cookie path so the same cookie is used for two different session managers?
>
> Stuart
>
> On Wed, Dec 20, 2017 at 4:49 PM, Eric B <ebenzacar at gmail.com> wrote:
>
>> Hi Stuart,
>>
>> Strangely enough, my web.xml does not have distributable defined.
>>
>> I managed to get the InMemorySessionManager working by using a servlet
>> extension, but I can't help but think I'm using a sledge hammer to
>> configure it that way.  I can't believe there isn't another way to enable
>> non distributable sessions.
>>
>> My application is a JEE ear with 2 web apps (using a shared session
>> cookie) and an EJB package if that makes a difference.
>>
>> Thanks
>>
>> Eric
>>
>>
>> On Dec 19, 2017 5:44 PM, "Stuart Douglas" <stuart.w.douglas at gmail.com>
>> wrote:
>>
>> If you remove <distributable/> from your web.xml you should just get the
>> InMemorySessionManager.
>>
>> Stuart
>>
>> On Wed, Dec 20, 2017 at 4:29 AM, Eric B <ebenzacar at gmail.com> wrote:
>>
>>> I've continued digging into my issue and noticed that the default
>>> DistributableSessionManager uses the org.wildfly.clustering.web
>>> .infinispan.session.InfinispanSessionManager, which I guess comes from
>>> the module parameter in the cache-container definition.
>>>
>>> Part of my problem is that I am trying to invalidate() the session
>>> returned by the SessionManager, but when I do a
>>> SessionManager.getSession(sessionId), it returns an
>>> DistributableImmutableSession whose invalidate() method intentionally does
>>> nothing.
>>>
>>> So how can I invalidate a session?  Is there no way to invalidate a
>>> session by sessionId with the DistributableSessionManager?  If so, how?  If
>>> not, how do I define a SessionManager that would give me access that?
>>>
>>> Thanks,
>>>
>>> Eric
>>>
>>> On Tue, Dec 19, 2017 at 11:38 AM, Eric B <ebenzacar at gmail.com> wrote:
>>>
>>>> Further to a previous post for session problems in my application, I
>>>> believe some of my issues relate to the DistributableSessions that are
>>>> being used by Wildfly.  However, in my configuration file, I have my web
>>>> cache defined as a local cache:
>>>>
>>>>
>>>>
>>>>         <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
>>>>             <cache-container name="server" aliases="singleton cluster"
>>>> default-cache="default" module="org.wildfly.clustering.server">
>>>>                 <transport lock-timeout="60000"/>
>>>>                 <replicated-cache name="default" mode="SYNC">
>>>>                     <transaction mode="BATCH"/>
>>>>                 </replicated-cache>
>>>>             </cache-container>
>>>>             <cache-container name="web" default-cache="passivation"
>>>> module="org.wildfly.clustering.web.infinispan">
>>>>                 <local-cache name="passivation">
>>>>                     <locking isolation="REPEATABLE_READ"/>
>>>>                     <transaction mode="BATCH"/>
>>>>                     <file-store passivation="true" purge="false"/>
>>>>                 </local-cache>
>>>>                 <local-cache name="persistent">
>>>>                     <locking isolation="REPEATABLE_READ"/>
>>>>                     <transaction mode="BATCH"/>
>>>>                     <file-store passivation="false" purge="false"/>
>>>>                 </local-cache>
>>>>             </cache-container>
>>>> ...
>>>> ...
>>>>
>>>>
>>>> I see that undertow comes with an InMemorySessionManager, but not
>>>> entirely sure how to enable it.  Do I have to go through the effort of
>>>> creating my own ServletExtension and configuring it in the
>>>> META-INF/services/io.undertow.servlet.ServletExtension or is there an
>>>> out-of-the-box way of enable functionality that already exists via the
>>>> config file?
>>>>
>>>> Thanks,
>>>>
>>>> Eric
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20171220/05b16bc9/attachment-0001.html 

From stuart.w.douglas at gmail.com  Wed Dec 20 19:09:43 2017
From: stuart.w.douglas at gmail.com (Stuart Douglas)
Date: Thu, 21 Dec 2017 11:09:43 +1100
Subject: [wildfly-dev] How to configure Wildfly to use the
 InMemorySessionManager instead of DistributableSessionManager?
In-Reply-To: <CA+T+PjG10PETh8tDhZWJccry4YzJyw++bO2jUB-VceM6j_wwkA@mail.gmail.com>
References: <CA+T+PjE445pHrDiw999-TO9kXdTtQ-4Jdg4mbt=2tVyQ=XCFCg@mail.gmail.com>
	<CA+T+PjEN5Pb77cNs3Vc0SQeq1ZQUog5ZQfs1HJoWZSQ3O3x+Hw@mail.gmail.com>
	<CAAoo=c7yO9AhVTokqT2MCMnzHAzsuKMWyPsnSFNiuVid7zD2Pw@mail.gmail.com>
	<CA+T+PjGgmUn+bQGA3kkKfzKm7TPGQiddU1o1i2S_2qrN=9_UXQ@mail.gmail.com>
	<CAAoo=c5BoCfAQgRNPtQy6X2FpGvBfJHGGn1GMEWvT=JdawJdxA@mail.gmail.com>
	<CA+T+PjG10PETh8tDhZWJccry4YzJyw++bO2jUB-VceM6j_wwkA@mail.gmail.com>
Message-ID: <CAAoo=c4mu4XZAXpJ7q_+1n54VnJuRGuUuoVTqCR3EOBp4FVDkg@mail.gmail.com>

It should be using this by default, unless the app is distributable. This
sounds like a bug. Do you have a reproducer I can look at? All I can think
of is that if you have a distributable web fragment in your app maybe we
are merging them incorrectly.

Stuart

On Wed, Dec 20, 2017 at 11:07 PM, Eric B <ebenzacar at gmail.com> wrote:

> I've changed the cookie path to / within the jboss-all.xml file in order
> for two war to share the same session.  (Each war has its own context path:
> /war1, /war).  I essentially need one war to be able to authenticate and
> authorize the user, and have that authentication/authorization carry over
> to the session in the other war.  I don't actually need to share the
> session other than for auth purposes.
>
> Is that feasible using the InMemorySessionManager?  Is there a way to
> ensure that they are all using the same InMemorySessionManager?
>
> Thanks
>
> Eric
>
> On Dec 20, 2017 1:10 AM, "Stuart Douglas" <stuart.w.douglas at gmail.com>
> wrote:
>
>> Are you using the shared session functionality? Or just overriding the
>> cookie path so the same cookie is used for two different session managers?
>>
>> Stuart
>>
>> On Wed, Dec 20, 2017 at 4:49 PM, Eric B <ebenzacar at gmail.com> wrote:
>>
>>> Hi Stuart,
>>>
>>> Strangely enough, my web.xml does not have distributable defined.
>>>
>>> I managed to get the InMemorySessionManager working by using a servlet
>>> extension, but I can't help but think I'm using a sledge hammer to
>>> configure it that way.  I can't believe there isn't another way to enable
>>> non distributable sessions.
>>>
>>> My application is a JEE ear with 2 web apps (using a shared session
>>> cookie) and an EJB package if that makes a difference.
>>>
>>> Thanks
>>>
>>> Eric
>>>
>>>
>>> On Dec 19, 2017 5:44 PM, "Stuart Douglas" <stuart.w.douglas at gmail.com>
>>> wrote:
>>>
>>> If you remove <distributable/> from your web.xml you should just get the
>>> InMemorySessionManager.
>>>
>>> Stuart
>>>
>>> On Wed, Dec 20, 2017 at 4:29 AM, Eric B <ebenzacar at gmail.com> wrote:
>>>
>>>> I've continued digging into my issue and noticed that the default
>>>> DistributableSessionManager uses the org.wildfly.clustering.web
>>>> .infinispan.session.InfinispanSessionManager, which I guess comes from
>>>> the module parameter in the cache-container definition.
>>>>
>>>> Part of my problem is that I am trying to invalidate() the session
>>>> returned by the SessionManager, but when I do a
>>>> SessionManager.getSession(sessionId), it returns an
>>>> DistributableImmutableSession whose invalidate() method intentionally does
>>>> nothing.
>>>>
>>>> So how can I invalidate a session?  Is there no way to invalidate a
>>>> session by sessionId with the DistributableSessionManager?  If so, how?  If
>>>> not, how do I define a SessionManager that would give me access that?
>>>>
>>>> Thanks,
>>>>
>>>> Eric
>>>>
>>>> On Tue, Dec 19, 2017 at 11:38 AM, Eric B <ebenzacar at gmail.com> wrote:
>>>>
>>>>> Further to a previous post for session problems in my application, I
>>>>> believe some of my issues relate to the DistributableSessions that are
>>>>> being used by Wildfly.  However, in my configuration file, I have my web
>>>>> cache defined as a local cache:
>>>>>
>>>>>
>>>>>
>>>>>         <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
>>>>>             <cache-container name="server" aliases="singleton cluster"
>>>>> default-cache="default" module="org.wildfly.clustering.server">
>>>>>                 <transport lock-timeout="60000"/>
>>>>>                 <replicated-cache name="default" mode="SYNC">
>>>>>                     <transaction mode="BATCH"/>
>>>>>                 </replicated-cache>
>>>>>             </cache-container>
>>>>>             <cache-container name="web" default-cache="passivation"
>>>>> module="org.wildfly.clustering.web.infinispan">
>>>>>                 <local-cache name="passivation">
>>>>>                     <locking isolation="REPEATABLE_READ"/>
>>>>>                     <transaction mode="BATCH"/>
>>>>>                     <file-store passivation="true" purge="false"/>
>>>>>                 </local-cache>
>>>>>                 <local-cache name="persistent">
>>>>>                     <locking isolation="REPEATABLE_READ"/>
>>>>>                     <transaction mode="BATCH"/>
>>>>>                     <file-store passivation="false" purge="false"/>
>>>>>                 </local-cache>
>>>>>             </cache-container>
>>>>> ...
>>>>> ...
>>>>>
>>>>>
>>>>> I see that undertow comes with an InMemorySessionManager, but not
>>>>> entirely sure how to enable it.  Do I have to go through the effort of
>>>>> creating my own ServletExtension and configuring it in the
>>>>> META-INF/services/io.undertow.servlet.ServletExtension or is there an
>>>>> out-of-the-box way of enable functionality that already exists via the
>>>>> config file?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eric
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20171221/1c250b1e/attachment.html 

From ebenzacar at gmail.com  Wed Dec 20 22:32:07 2017
From: ebenzacar at gmail.com (Eric B)
Date: Wed, 20 Dec 2017 22:32:07 -0500
Subject: [wildfly-dev] How to configure Wildfly to use the
 InMemorySessionManager instead of DistributableSessionManager?
In-Reply-To: <CAAoo=c4mu4XZAXpJ7q_+1n54VnJuRGuUuoVTqCR3EOBp4FVDkg@mail.gmail.com>
References: <CA+T+PjE445pHrDiw999-TO9kXdTtQ-4Jdg4mbt=2tVyQ=XCFCg@mail.gmail.com>
	<CA+T+PjEN5Pb77cNs3Vc0SQeq1ZQUog5ZQfs1HJoWZSQ3O3x+Hw@mail.gmail.com>
	<CAAoo=c7yO9AhVTokqT2MCMnzHAzsuKMWyPsnSFNiuVid7zD2Pw@mail.gmail.com>
	<CA+T+PjGgmUn+bQGA3kkKfzKm7TPGQiddU1o1i2S_2qrN=9_UXQ@mail.gmail.com>
	<CAAoo=c5BoCfAQgRNPtQy6X2FpGvBfJHGGn1GMEWvT=JdawJdxA@mail.gmail.com>
	<CA+T+PjG10PETh8tDhZWJccry4YzJyw++bO2jUB-VceM6j_wwkA@mail.gmail.com>
	<CAAoo=c4mu4XZAXpJ7q_+1n54VnJuRGuUuoVTqCR3EOBp4FVDkg@mail.gmail.com>
Message-ID: <CA+T+PjHhtwr=g5qW48K7WWEUyyPS9YNBZ69mXdYva+2hk4h88A@mail.gmail.com>

The jboss-all.xml has the following content:

<jboss umlns="urn:jboss:1.0">
  <shared-session-config xmlns="urn:jboss:shared-session-config:1.0">
    <session-config>
      <session-timeout>30</session-timeout>
      <cookie-config>
        <name>JSESSIONID_NG</name>
        <path>/</path>
        <comment>cookie comment</comment>
        <max-age>-1</max-age>
      </cookie-config>
    </session-config>
  </shared-session-config>
</jboss>


Does that mean that it must use distributable session manager?   Or should
shared sessions like that still be able to work with the
InMemorySessionManager?  Of course, I realize that it would have to be the
same IMSM used in all apps.

If not I'll have to see if I can reproduce this with a POC rather than my
huge monolith.

Thanks,

Eric


On Wed, Dec 20, 2017 at 7:09 PM, Stuart Douglas <stuart.w.douglas at gmail.com>
wrote:

> It should be using this by default, unless the app is distributable. This
> sounds like a bug. Do you have a reproducer I can look at? All I can think
> of is that if you have a distributable web fragment in your app maybe we
> are merging them incorrectly.
>
> Stuart
>
> On Wed, Dec 20, 2017 at 11:07 PM, Eric B <ebenzacar at gmail.com> wrote:
>
>> I've changed the cookie path to / within the jboss-all.xml file in order
>> for two war to share the same session.  (Each war has its own context path:
>> /war1, /war).  I essentially need one war to be able to authenticate and
>> authorize the user, and have that authentication/authorization carry over
>> to the session in the other war.  I don't actually need to share the
>> session other than for auth purposes.
>>
>> Is that feasible using the InMemorySessionManager?  Is there a way to
>> ensure that they are all using the same InMemorySessionManager?
>>
>> Thanks
>>
>> Eric
>>
>> On Dec 20, 2017 1:10 AM, "Stuart Douglas" <stuart.w.douglas at gmail.com>
>> wrote:
>>
>>> Are you using the shared session functionality? Or just overriding the
>>> cookie path so the same cookie is used for two different session managers?
>>>
>>> Stuart
>>>
>>> On Wed, Dec 20, 2017 at 4:49 PM, Eric B <ebenzacar at gmail.com> wrote:
>>>
>>>> Hi Stuart,
>>>>
>>>> Strangely enough, my web.xml does not have distributable defined.
>>>>
>>>> I managed to get the InMemorySessionManager working by using a servlet
>>>> extension, but I can't help but think I'm using a sledge hammer to
>>>> configure it that way.  I can't believe there isn't another way to enable
>>>> non distributable sessions.
>>>>
>>>> My application is a JEE ear with 2 web apps (using a shared session
>>>> cookie) and an EJB package if that makes a difference.
>>>>
>>>> Thanks
>>>>
>>>> Eric
>>>>
>>>>
>>>> On Dec 19, 2017 5:44 PM, "Stuart Douglas" <stuart.w.douglas at gmail.com>
>>>> wrote:
>>>>
>>>> If you remove <distributable/> from your web.xml you should just get
>>>> the InMemorySessionManager.
>>>>
>>>> Stuart
>>>>
>>>> On Wed, Dec 20, 2017 at 4:29 AM, Eric B <ebenzacar at gmail.com> wrote:
>>>>
>>>>> I've continued digging into my issue and noticed that the default
>>>>> DistributableSessionManager uses the org.wildfly.clustering.web
>>>>> .infinispan.session.InfinispanSessionManager, which I guess comes
>>>>> from the module parameter in the cache-container definition.
>>>>>
>>>>> Part of my problem is that I am trying to invalidate() the session
>>>>> returned by the SessionManager, but when I do a
>>>>> SessionManager.getSession(sessionId), it returns an
>>>>> DistributableImmutableSession whose invalidate() method intentionally does
>>>>> nothing.
>>>>>
>>>>> So how can I invalidate a session?  Is there no way to invalidate a
>>>>> session by sessionId with the DistributableSessionManager?  If so, how?  If
>>>>> not, how do I define a SessionManager that would give me access that?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Eric
>>>>>
>>>>> On Tue, Dec 19, 2017 at 11:38 AM, Eric B <ebenzacar at gmail.com> wrote:
>>>>>
>>>>>> Further to a previous post for session problems in my application, I
>>>>>> believe some of my issues relate to the DistributableSessions that are
>>>>>> being used by Wildfly.  However, in my configuration file, I have my web
>>>>>> cache defined as a local cache:
>>>>>>
>>>>>>
>>>>>>
>>>>>>         <subsystem xmlns="urn:jboss:domain:infinispan:4.0">
>>>>>>             <cache-container name="server" aliases="singleton
>>>>>> cluster" default-cache="default" module="org.wildfly.clustering
>>>>>> .server">
>>>>>>                 <transport lock-timeout="60000"/>
>>>>>>                 <replicated-cache name="default" mode="SYNC">
>>>>>>                     <transaction mode="BATCH"/>
>>>>>>                 </replicated-cache>
>>>>>>             </cache-container>
>>>>>>             <cache-container name="web" default-cache="passivation"
>>>>>> module="org.wildfly.clustering.web.infinispan">
>>>>>>                 <local-cache name="passivation">
>>>>>>                     <locking isolation="REPEATABLE_READ"/>
>>>>>>                     <transaction mode="BATCH"/>
>>>>>>                     <file-store passivation="true" purge="false"/>
>>>>>>                 </local-cache>
>>>>>>                 <local-cache name="persistent">
>>>>>>                     <locking isolation="REPEATABLE_READ"/>
>>>>>>                     <transaction mode="BATCH"/>
>>>>>>                     <file-store passivation="false" purge="false"/>
>>>>>>                 </local-cache>
>>>>>>             </cache-container>
>>>>>> ...
>>>>>> ...
>>>>>>
>>>>>>
>>>>>> I see that undertow comes with an InMemorySessionManager, but not
>>>>>> entirely sure how to enable it.  Do I have to go through the effort of
>>>>>> creating my own ServletExtension and configuring it in the
>>>>>> META-INF/services/io.undertow.servlet.ServletExtension or is there
>>>>>> an out-of-the-box way of enable functionality that already exists via the
>>>>>> config file?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/20171220/d78139eb/attachment-0001.html