From tom.jenkinson at redhat.com  Tue May  1 04:09:01 2018
From: tom.jenkinson at redhat.com (Tom Jenkinson)
Date: Tue, 1 May 2018 09:09:01 +0100
Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan
 Openshift Template
In-Reply-To: <CAA9R9O7rYHmN6zSk+oP43Je3a4DQBjZw_+Ox9RmG5HbH5WnBag@mail.gmail.com>
References: <CAFm4XO1sd48hcd76PF6THjXpExzKoHC=GgU7BwEUnwRV8o=avw@mail.gmail.com>
	<CAA9R9O77sdZA3b=AXudPmBUrfZXYJXU+3+KGzeV7H=BJ=7PcNQ@mail.gmail.com>
	<CAFm4XO1Ld81pjqfvw7G+EXit+uYkkJKtzpi=fYvkh1Sr-hhofw@mail.gmail.com>
	<CAA9R9O6ZfZ3HzpOQs0dnNvrvGB0tPR_T9qZSvCh1aaKP3qjotw@mail.gmail.com>
	<CAFMDs3DFJZd5LkhVwhzdyTQ15VskgcRgCLiAgAc5rkCDwdpVhQ@mail.gmail.com>
	<CAA9R9O77t21M=D8bMoQp7HsvHMsTQO2J_+k_iKgKQucNLZWeMA@mail.gmail.com>
	<CALaezvUOXKEE87iTagAnE-Dnx2SYGefmGOTbVkih0R_X-HuUQQ@mail.gmail.com>
	<CAA9R9O6HJk+CAC7X4QG07zO3Wtq8=rVq9we5UCKUmywjVENZ2A@mail.gmail.com>
	<CALaezvVJLuv4OYqdKk73gNLPiUyE2h-FQtU5dF8xfc-7XFPaFg@mail.gmail.com>
	<CAA9R9O7rYHmN6zSk+oP43Je3a4DQBjZw_+Ox9RmG5HbH5WnBag@mail.gmail.com>
Message-ID: <CALaezvVTZxFDo+auOALk3tjXC1nkTShZuZu5364GQFSNrcPFtg@mail.gmail.com>

I am not sure - the default should be "1" for the bare metal case so the
warning is reliably triggered but the default can be the pod name for
OpenShift templates that only allow a single instance of the application
server - does that help?

The file you looked to want to edit is shared by bare metal and other
deployment environments so it would be confusing to set the default to
jboss.node.name there IMO.

On 1 May 2018 at 03:39, Sebastian Laskawiec <slaskawi at redhat.com> wrote:

> Fair enough Tom. Thanks for explanation.
>
> One more request - would you guys be OK with me adding
> a node-identifier="${jboss.node.name}" to the transaction subsystem
> template [1]? This way we wouldn't need to copy it into Infinispan (since
> we need to set it).
>
> [1] https://github.com/wildfly/wildfly/blob/master/transactions/src/main/
> resources/subsystem-templates/transactions.xml#L6
>
> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
>
>> On 18 April 2018 at 14:07, Sebastian Laskawiec <slaskawi at redhat.com>
>> wrote:
>>
>>> Hey Tom,
>>>
>>> Comments inlined.
>>>
>>> Thanks,
>>> Sebastian
>>>
>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson <tom.jenkinson at redhat.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 16 April 2018 at 09:31, <> wrote:
>>>>
>>>>> Adding +WildFly Dev <wildfly-dev at lists.jboss.org> to the loop
>>>>
>>>>
>>>>>
>>>>> Thanks for the explanation Rado.
>>>>>
>>>>> TL;DR: A while ago Sanne pointed out that we do not set
>>>>> `node-identifier`
>>>>> in transaction subsystem by default. The default value for the
>>>>> `node-identifier` attribute it `1`. Not setting this attribute might
>>>>> cause
>>>>> problems in transaction recovery. Perhaps we could follow Rado's idea
>>>>> and
>>>>> set it to node name by default?
>>>>>
>>>> Indeed - it would cause serious data integrity problems if a non-unique
>>>> node-identifier is used.
>>>>
>>>>> Some more comments inlined.
>>>>>
>>>>> Thanks,
>>>>> Sebastian
>>>>>
>>>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar <rhusar at redhat.com>
>>>>> wrote:
>>>>>
>>>>> > Hi Sebastian,
>>>>> >
>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec
>>>>> > <slaskawi at redhat.com> wrote:
>>>>> > > Hey Rado, Paul,
>>>>> > >
>>>>> > > I started looking into this issue and it turned out that WF
>>>>> subsystem
>>>>> > > template doesn't provide `node-identifier` attribute [1].
>>>>> >
>>>>> > I assume you mean that the default WildFly server profiles do not
>>>>>
>>>> > explicitly define the attribute. Right ? thus the value defaults in
>>>>
>>>>
>>>>> > the model to "1"
>>>>> >
>>>>> > https://github.com/wildfly/wildfly/blob/master/
>>>>> transactions/src/main/java/org/jboss/as/txn/subsystem/
>>>>> TransactionSubsystemRootResourceDefinition.java#L97
>>>>> > which sole intention seems to be to log a warning on boot if the
>>>>> value
>>>>> > is unchanged.
>>>>> > Why they decided on a constant that will be inherently not unique as
>>>>> > opposed to defaulting to the node name (which we already require to
>>>>> be
>>>>> > unique) as clustering node name or undertow instance-id does, is
>>>>> > unclear to me.
>>>>> > Some context is on https://issues.jboss.org/browse/WFLY-1119.
>>>>> >
>>>>>
>>>>> In OpenShift environment we could set it to `hostname`. This is
>>>>> guaranteed
>>>>> to be unique in whole OpenShift cluster.
>>>>>
>>>>>
>>>>> We do this too in EAP images.
>>>> To Rado's point, the default is "1" so we can print the warning to
>>>> alert people they are misconfigured - it seems to be working :)
>>>>
>>>
>>> This is the point. From my understanding, if we set it to node name
>>> (instead of "1"), we could make it always work correctly. We could even
>>> remove the code that emits the warning (since the node name needs to be
>>> unique).
>>>
>>> To sum it up - if we decided to proceed this way, there would be no
>>> requirement of setting the node-identifier at all.
>>>
>>
>> For OpenShift you are right there is no requirement for someone to change
>> the node-identifier from the podname and so that is why EAP images do that.
>>
>> For bare-metal it is different as there can be two servers on the same
>> machine so they were configured to use the hostname as they node-identifier
>> then if they were also connected to the same resource managers or the same
>> object store they would interfere with each other.
>>
>>
>>>
>>>
>>>>
>>>>
>>>>> >
>>>>
>>>>
>>>>> > > I'm not sure if you guys are the right people to ask, but is it
>>>>> safe to
>>>>> > > leave it set to default? Or shall I override our Infinispan
>>>>> templates and
>>>>> > > add this parameter (as I mentioned before, in OpenShift this I
>>>>> wanted to
>>>>> > set
>>>>> > > it as Pod name trimmed to the last 23 chars since this is the
>>>>> limit).
>>>>>
>>>> Putting a response to this in line - I am not certain who originally
>>>> proposed this.
>>>>
>>>> You must use a globally unique node-identifier. If you are certain the
>>>> last 23 characters guarantee that it would be valid - if there is a chance
>>>> they are not unique it is not valid to trim.
>>>>
>>>
>>> If that's not an issue, again, we could use the same limit as we have
>>> for node name.
>>>
>>>
>>>>
>>>>
>>>>
>>>>> >
>>>>
>>>>
>>>>> > It is not safe to leave it set to "1" as that results in inconsistent
>>>>> > processing of transaction recovery.
>>>>> > IIUC we already set it to the node name for both EAP and JDG
>>>>> >
>>>>> > https://github.com/jboss-openshift/cct_module/blob/
>>>>> master/os-eap70-openshift/added/standalone-openshift.xml#L411
>>>>> >
>>>>> > https://github.com/jboss-openshift/cct_module/blob/
>>>>> master/os-jdg7-conffiles/added/clustered-openshift.xml#L282
>>>>>
>>>> > which in turn defaults to the pod name ? so which profiles are we
>>>>
>>>>
>>>>> > talking about here?
>>>>> >
>>>>>
>>>>> Granted, we set it by default in CCT Modules. However in Infinispan we
>>>>> just
>>>>> grab provided transaction subsystem when rendering full configuration
>>>>> from
>>>>> featurepacks:
>>>>> https://github.com/infinispan/infinispan/blob/master/server/
>>>>> integration/feature-pack/src/main/resources/configuration/
>>>>> standalone/subsystems-cloud.xml#L19
>>>>>
>>>>> The default configuration XML doesn't contain the `node-identifier`
>>>>> attribute. I can add it manually in the cloud.xml but I believe the
>>>>> right
>>>>> approach is to modify the transaction subsystem.
>>>>>
>>>>>
>>>>> > Rado
>>>>> >
>>>>> > > Thanks,
>>>>> > > Seb
>>>>> > >
>>>>> > > [1] usually set to node-identifier="${jboss.node.name}"
>>>>> > >
>>>>> > >
>>>>>
>>>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero <sanne at
>>>>> infinispan.org>
>>>>> > > wrote:
>>>>> > >>
>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec <slaskawi at
>>>>> redhat.com>
>>>>
>>>>
>>>>> > wrote:
>>>>> > >> > Thanks for looking into it Sanne. Of course, we should add it
>>>>> (it can
>>>>> > be
>>>>> > >> > set
>>>>> > >> > to the same name as hostname since those are unique in
>>>>> Kubernetes).
>>>>> > >> >
>>>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 for it.
>>>>> > >> >
>>>>> > >> > Thanks again!
>>>>> > >> > Seb
>>>>> > >>
>>>>> > >> Thanks Sebastian!
>>>>> > >>
>>>>> > >> >
>>>>>
>>>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero <sanne at
>>>>> infinispan.org>
>>>>
>>>>
>>>>> > >> > wrote:
>>>>> > >> >>
>>>>> > >> >> Hi all,
>>>>> > >> >>
>>>>> > >> >> I've started to use the Infinispan Openshift Template and was
>>>>> > browsing
>>>>> > >> >> through the errors and warnings this produces.
>>>>> > >> >>
>>>>> > >> >> In particular I noticed "WFLYTX0013: Node identifier property
>>>>> is set
>>>>> > >> >> to the default value. Please make sure it is unique." being
>>>>> produced
>>>>> > >> >> by the transaction system.
>>>>> > >> >>
>>>>> > >> >> The node id is usually not needed for developer's convenience
>>>>> and
>>>>> > >> >> assuming there's a single node in "dev mode", yet clearly the
>>>>> > >> >> Infinispan template is meant to work with multiple nodes
>>>>> running so
>>>>> > >> >> this warning seems concerning.
>>>>> > >> >>
>>>>> > >> >> I'm not sure what the impact is on the transaction manager so
>>>>> I asked
>>>>> > >> >> on the Narayana forums; Tom pointed me to some thourough design
>>>>> > >> >> documents and also suggested the EAP image does set the node
>>>>> > >> >> identifier:
>>>>> > >> >>  - https://developer.jboss.org/message/981702#981702
>>>>> > >> >>
>>>>> > >> >> WDYT? we probably want the Infinispan template to set this as
>>>>> well,
>>>>> > or
>>>>> > >> >> silence the warning?
>>>>> > >> >>
>>>>> > >> >> Thanks,
>>>>> > >> >> Sanne
>>>>> > >> >> _______________________________________________
>>>>> > >> >> infinispan-dev mailing list
>>>>>
>>>> > >> >> infinispan-dev at lists.jboss.org
>>>>
>>>>
>>>>> > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>> > >> >
>>>>> > >> >
>>>>> > >> > _______________________________________________
>>>>> > >> > infinispan-dev mailing list
>>>>>
>>>> > >> > infinispan-dev at lists.jboss.org
>>>>
>>>>
>>>>> > >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>> > >> _______________________________________________
>>>>> > >> infinispan-dev mailing list
>>>>> > >> infinispan-dev at lists.jboss.org
>>>>> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>> >
>>>>> -------------- next part --------------
>>>>> An HTML attachment was scrubbed...
>>>>> URL: http://lists.jboss.org/pipermail/wildfly-dev/
>>>>> attachments/20180416/65962cf1/attachment-0001.html
>>>>>
>>>>>
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180501/f6e0421d/attachment-0001.html 

From ppalaga at redhat.com  Wed May  2 17:49:03 2018
From: ppalaga at redhat.com (Peter Palaga)
Date: Wed, 2 May 2018 23:49:03 +0200
Subject: [wildfly-dev] How to secure Camel CXF endpoints with Elytron?
Message-ID: <ff62a174-15e3-4809-b7cd-9820cb863433@redhat.com>

Hi all, esp. Darran and Stuart,

We (WildFly Camel Team) have a request [1] to support securing Camel CXF 
endpoints with Elytron and I am trying to figure out the best way to 
achieve that.

= Current state

A Camel context is started by Weld during 
Phase.INSTALL_CDI_VALIDATOR_FACTORY. This triggers a creation of the CXF 
WS endpoint. To expose the endpoint on Undertow, we create an ad hoc 
DeploymentInfo [2] with a context path requested by the Camel route [3].

To handle security, users are suggested to use CXF Interceptors, such as 
JAASLoginInterceptor [4]. The JAASLoginInterceptor works well with 
security domains defined in the legacy Security subsystem.

= The problem

A user wants to get rid of the legacy Security subsystem and use Elytron 
instead.

= How to solve it

As Darran pointed out in the chat, there is no JAAS support in Elytron 
and we thus cannot keep relying on JAASLoginInterceptor & Co.

I investigated how Elytron is integrated in Undertow subsystem (esp. 
UndertowDeploymentInfoService) and I tried to do the same for our custom 
DeploymentInfo in Camel subsystem. The key point was to obtain a 
reference to securityFunction and apply it to the DeploymentInfo. In 
this way our Camel CXF endpoints indeed got protected by an Elytron 
security domain.

I have a dirty but working PoC [5] where I just copied parts of 
UndertowDeploymentInfoService to a new CamelDynamicDeploymentService.

I'd like to try re-using UndertowDeploymentInfoService as a whole so 
that I do not duplicate the security sensitive code. But before I do, 
could you Darran, Stuart and others please approve the general idea or 
eventually suggest something better?

Thanks,

-- Peter

[1] https://issues.jboss.org/browse/ENTESB-7959
[2] 
https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/main/java/org/apache/cxf/transport/undertow/wildfly/WildflyHTTPServerEngine.java#L64
[3] 
https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/main/java/org/apache/cxf/transport/undertow/wildfly/WildflyHTTPServerEngine.java#L66
[4] 
https://github.com/wildfly-extras/wildfly-camel-examples/blob/6.0.0/camel-cxf-jaxws-cdi-secure/src/main/java/org/wildfly/camel/examples/cxf/jaxws/Application.java#L112
[5] https://github.com/ppalaga/wildfly-camel/commits/ENTESB-7959.180430

From darran.lofthouse at redhat.com  Thu May  3 06:19:55 2018
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Thu, 03 May 2018 10:19:55 +0000
Subject: [wildfly-dev] How to secure Camel CXF endpoints with Elytron?
In-Reply-To: <ff62a174-15e3-4809-b7cd-9820cb863433@redhat.com>
References: <ff62a174-15e3-4809-b7cd-9820cb863433@redhat.com>
Message-ID: <CAMxVf4NQ7azP+1+nhTKUFr9_mSseMYDiYDWjrvyE+qFc0=VTAQ@mail.gmail.com>

I think on this one it is worth starting with some of the history and then
some of the planned next steps as overall I think anything developed here
should consider how we plan to evolve the configuration.

At the time we added WildFly Elytron it was a new security solution for the
application server, all deployments that already existed would be using
PicketBox based security so we wanted a solution that would allow the
existing deployments to continue to work 'as-is' whilst allowing new
deployments to make use of WildFly Elytron and to allow administrators the
choice to migrate their deployments to WildFly Elytron.  This is the reason
we added mappings to both the EJB and Undertow subsystems, if we don't
match on a mapping then assume they want PicketBox, if we do match on a
mapping apply Elytron based security.

There is one gap in this mapping that is likely to be changing soon,
presently the mapping only maps to a http-authentication-factory - for a
change I am in the process of making, for the Web Services integration and
I assume your integration this factory is not really required - in general
these type of integrations only require the SecurityDomain.  So that is one
change I plan to make, the mapping could specify a SecurityDomain instead
of the http-authentication-factory.

The SecurityDomain is already automatically associated with the ClassLoader
of the deployment but we could reach a point in the future where if the
domain is available it is attached to the DeploymentInfo so if something
else wants to make use of it it just needs to check if it is attached - we
could still add some of our handlers such as the one to associate the
flexible identity.

At a slightly later point I do also need to look at how we can active the
Elytron integration without requiring the mapping, I don't know if this
would be using the existing elements and annotations or if we would want
something specifically related to Elytron so that would need to be a later
discussion.

But overall at this stage I wonder if we would be better to ensure we are
dealing with attachments to the DeploymentInfo rather than getting too
tightly tied to the application security domain mappings which is something
we know will need to evolve further possibly to the point it is eliminated.

Regards,
Darran Lofthouse.


On Wed, 2 May 2018 at 22:49 Peter Palaga <ppalaga at redhat.com> wrote:

> Hi all, esp. Darran and Stuart,
>
> We (WildFly Camel Team) have a request [1] to support securing Camel CXF
> endpoints with Elytron and I am trying to figure out the best way to
> achieve that.
>
> = Current state
>
> A Camel context is started by Weld during
> Phase.INSTALL_CDI_VALIDATOR_FACTORY. This triggers a creation of the CXF
> WS endpoint. To expose the endpoint on Undertow, we create an ad hoc
> DeploymentInfo [2] with a context path requested by the Camel route [3].
>
> To handle security, users are suggested to use CXF Interceptors, such as
> JAASLoginInterceptor [4]. The JAASLoginInterceptor works well with
> security domains defined in the legacy Security subsystem.
>
> = The problem
>
> A user wants to get rid of the legacy Security subsystem and use Elytron
> instead.
>
> = How to solve it
>
> As Darran pointed out in the chat, there is no JAAS support in Elytron
> and we thus cannot keep relying on JAASLoginInterceptor & Co.
>
> I investigated how Elytron is integrated in Undertow subsystem (esp.
> UndertowDeploymentInfoService) and I tried to do the same for our custom
> DeploymentInfo in Camel subsystem. The key point was to obtain a
> reference to securityFunction and apply it to the DeploymentInfo. In
> this way our Camel CXF endpoints indeed got protected by an Elytron
> security domain.
>
> I have a dirty but working PoC [5] where I just copied parts of
> UndertowDeploymentInfoService to a new CamelDynamicDeploymentService.
>
> I'd like to try re-using UndertowDeploymentInfoService as a whole so
> that I do not duplicate the security sensitive code. But before I do,
> could you Darran, Stuart and others please approve the general idea or
> eventually suggest something better?
>
> Thanks,
>
> -- Peter
>
> [1] https://issues.jboss.org/browse/ENTESB-7959
> [2]
>
> https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/main/java/org/apache/cxf/transport/undertow/wildfly/WildflyHTTPServerEngine.java#L64
> [3]
>
> https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/main/java/org/apache/cxf/transport/undertow/wildfly/WildflyHTTPServerEngine.java#L66
> [4]
>
> https://github.com/wildfly-extras/wildfly-camel-examples/blob/6.0.0/camel-cxf-jaxws-cdi-secure/src/main/java/org/wildfly/camel/examples/cxf/jaxws/Application.java#L112
> [5] https://github.com/ppalaga/wildfly-camel/commits/ENTESB-7959.180430
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180503/2bc41e76/attachment.html 

From ppalaga at redhat.com  Thu May  3 11:48:04 2018
From: ppalaga at redhat.com (Peter Palaga)
Date: Thu, 3 May 2018 17:48:04 +0200
Subject: [wildfly-dev] How to secure Camel CXF endpoints with Elytron?
In-Reply-To: <CAMxVf4NQ7azP+1+nhTKUFr9_mSseMYDiYDWjrvyE+qFc0=VTAQ@mail.gmail.com>
References: <ff62a174-15e3-4809-b7cd-9820cb863433@redhat.com>
	<CAMxVf4NQ7azP+1+nhTKUFr9_mSseMYDiYDWjrvyE+qFc0=VTAQ@mail.gmail.com>
Message-ID: <0c9f6ec3-a3c1-fa08-f4fb-68c376be9254@redhat.com>

Hi Darran, thanks for the info, more inline...

On 03/05/18 12:19, Darran Lofthouse wrote:
> I think on this one it is worth starting with some of the history and 
> then some of the planned next steps as overall I think anything 
> developed here should consider how we plan to evolve the configuration.
> 
> At the time we added WildFly Elytron it was a new security solution for 
> the application server, all deployments that already existed would be 
> using PicketBox based security so we wanted a solution that would allow 
> the existing deployments to continue to work 'as-is' whilst allowing new 
> deployments to make use of WildFly Elytron and to allow administrators 
> the choice to migrate their deployments to WildFly Elytron.? This is the 
> reason we added mappings to both the EJB and Undertow subsystems, if we 
> don't match on a mapping then assume they want PicketBox, if we do match 
> on a mapping apply Elytron based security.
> 
> There is one gap in this mapping that is likely to be changing soon, 
> presently the mapping only maps to a http-authentication-factory - for a 
> change I am in the process of making, for the Web Services integration 
> and I assume your integration this factory is not really required - in 
> general these type of integrations only require the SecurityDomain.? So 
> that is one change I plan to make, the mapping could specify a 
> SecurityDomain instead of the http-authentication-factory.
> 
> The SecurityDomain is already automatically associated with the 
> ClassLoader of the deployment but we could reach a point in the future 
> where if the domain is available it is attached to the DeploymentInfo so 
> if something else wants to make use of it it just needs to check if it 
> is attached - we could still add some of our handlers such as the one to 
> associate the flexible identity.
> 
> At a slightly later point I do also need to look at how we can active 
> the Elytron integration without requiring the mapping, I don't know if 
> this would be using the existing elements and annotations or if we would 
> want something specifically related to Elytron so that would need to be 
> a later discussion.
> 
> But overall at this stage I wonder if we would be better to ensure we 
> are dealing with attachments to the DeploymentInfo rather than getting 
> too tightly tied to the application security domain mappings which is 
> something we know will need to evolve further possibly to the point it 
> is eliminated.

WildFly Camel applications contain resources of two kinds:

(1) Resources deployed and served as usual in EE web apps (servlets, 
static content, JSPs, traditional RS/WS, ...)

(2) Camel endpoints, such as CXF WS endpoints, that require special handling

There is no problem with securing (1). Everything works as expected there.

The problem we have relates exclusively to (2). I am saying this because 
what you said seems to be related to (1) rather than (2) (sorry if I 
misunderstood).

Let me try to explain again how the Camel CXF endpoints misfit the world 
of traditional EE concepts and what we are trying to achieve.

A simple Camel route may look like this:

new RouteBuilder().from("direct:start")
.to("cxf://http://localhost:8080/webservices/my-ws")?serviceClass=...")
...

The meaning is what you'd guess: If I write something to "direct:start", 
it gets routed to http://localhost:8080/webservices/my-ws.

To deploy this route on WildFly Camel, one packs the class into a war. 
The war and the resulting application can be called anyhow. Let's say 
ours is called "my-app.war" and you maybe already see the problem:
my-app.war gets deployed under some context path, by default /my-app, 
whereas its CXF endpoints may be located outside of that path. The 
endpoint in the example above has path /webservices/my-ws and there is 
no common prefix with /my-app.

To be able to expose the endpoint, we cannot use any traditional means 
such as servlet, because a servlet coming from my-app might only serve 
paths under /my-app. We have to rely on the lower level API of Undertow.
In particular, we create a custom DeploymentInfo with the requested 
context path and then we register it on Undertow.

What we'd like to achieve now is that the DeploymentInfo gets somehow 
magically all security aspects configured as if it was a traditional 
resource from /my-app.

I think that rather than creating the CXF endpoint DeploymentInfo from 
scratch, we should try cloning the the main app's DeploymentInfo 
(because that one already has the security set up properly) and 
customize only the parts that are supposed to be different, most 
prominently the context path. It seems to be feasible when looking at 
UndertowDeploymentInfoService.

Any comments on that?

Thanks,

-- Peter


> Regards,
> Darran Lofthouse.
> 
> 
> On Wed, 2 May 2018 at 22:49 Peter Palaga <ppalaga at redhat.com 
> <mailto:ppalaga at redhat.com>> wrote:
> 
>     Hi all, esp. Darran and Stuart,
> 
>     We (WildFly Camel Team) have a request [1] to support securing Camel
>     CXF
>     endpoints with Elytron and I am trying to figure out the best way to
>     achieve that.
> 
>     = Current state
> 
>     A Camel context is started by Weld during
>     Phase.INSTALL_CDI_VALIDATOR_FACTORY. This triggers a creation of the
>     CXF
>     WS endpoint. To expose the endpoint on Undertow, we create an ad hoc
>     DeploymentInfo [2] with a context path requested by the Camel route [3].
> 
>     To handle security, users are suggested to use CXF Interceptors,
>     such as
>     JAASLoginInterceptor [4]. The JAASLoginInterceptor works well with
>     security domains defined in the legacy Security subsystem.
> 
>     = The problem
> 
>     A user wants to get rid of the legacy Security subsystem and use
>     Elytron
>     instead.
> 
>     = How to solve it
> 
>     As Darran pointed out in the chat, there is no JAAS support in Elytron
>     and we thus cannot keep relying on JAASLoginInterceptor & Co.
> 
>     I investigated how Elytron is integrated in Undertow subsystem (esp.
>     UndertowDeploymentInfoService) and I tried to do the same for our
>     custom
>     DeploymentInfo in Camel subsystem. The key point was to obtain a
>     reference to securityFunction and apply it to the DeploymentInfo. In
>     this way our Camel CXF endpoints indeed got protected by an Elytron
>     security domain.
> 
>     I have a dirty but working PoC [5] where I just copied parts of
>     UndertowDeploymentInfoService to a new CamelDynamicDeploymentService.
> 
>     I'd like to try re-using UndertowDeploymentInfoService as a whole so
>     that I do not duplicate the security sensitive code. But before I do,
>     could you Darran, Stuart and others please approve the general idea or
>     eventually suggest something better?
> 
>     Thanks,
> 
>     -- Peter
> 
>     [1] https://issues.jboss.org/browse/ENTESB-7959
>     [2]
>     https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/main/java/org/apache/cxf/transport/undertow/wildfly/WildflyHTTPServerEngine.java#L64
>     [3]
>     https://github.com/wildfly-extras/wildfly-camel/blob/6.0.0/cxfhttp/src/main/java/org/apache/cxf/transport/undertow/wildfly/WildflyHTTPServerEngine.java#L66
>     [4]
>     https://github.com/wildfly-extras/wildfly-camel-examples/blob/6.0.0/camel-cxf-jaxws-cdi-secure/src/main/java/org/wildfly/camel/examples/cxf/jaxws/Application.java#L112
>     [5] https://github.com/ppalaga/wildfly-camel/commits/ENTESB-7959.180430
> 


From david.lloyd at redhat.com  Fri May  4 16:53:03 2018
From: david.lloyd at redhat.com (David Lloyd)
Date: Fri, 4 May 2018 15:53:03 -0500
Subject: [wildfly-dev] Proposal to revert component-matrix change
Message-ID: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>

I propose we revert the component-matrix change.  This change is
ostensibly to help in the creation of a BOM for the client libraries
and other dependent projects; however, the cost has turned out to be
somewhat higher than expected.

IntelliJ seems to be unable to cope with dependency changes in the
project due to the use of import from the root POM.  This means that
the entire project must be force-reimported from time to time to keep
dependencies up to date, and forgetting to do so can lead to
development issues and lost time.

Also, I've observed that Maven itself does not always correctly
resolve versions anymore, when you're building from a submodule.  I
don't really know why this is the case but I suspect that it's due to
some algorithmic ambiguity when the dependency tree is not linear like
it used to be.

I think that if we need to generate some BOM for use by external
projects, it should be done as a separate step and artifact which
acquires versions from the parent.  I believe we had it this way at
one point, didn't we?

Anyway I think this change didn't work out, and we should undo it
while it's still remotely possible.  WDYT?

-- 
- DML

From jason.greene at redhat.com  Fri May  4 17:04:16 2018
From: jason.greene at redhat.com (Jason Greene)
Date: Fri, 4 May 2018 17:04:16 -0400
Subject: [wildfly-dev] Proposal to revert component-matrix change
In-Reply-To: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
References: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
Message-ID: <CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>

I agree. We can break the bom cycle a different way.

> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd at redhat.com> wrote:
>
> I propose we revert the component-matrix change.  This change is
> ostensibly to help in the creation of a BOM for the client libraries
> and other dependent projects; however, the cost has turned out to be
> somewhat higher than expected.
>
> IntelliJ seems to be unable to cope with dependency changes in the
> project due to the use of import from the root POM.  This means that
> the entire project must be force-reimported from time to time to keep
> dependencies up to date, and forgetting to do so can lead to
> development issues and lost time.
>
> Also, I've observed that Maven itself does not always correctly
> resolve versions anymore, when you're building from a submodule.  I
> don't really know why this is the case but I suspect that it's due to
> some algorithmic ambiguity when the dependency tree is not linear like
> it used to be.
>
> I think that if we need to generate some BOM for use by external
> projects, it should be done as a separate step and artifact which
> acquires versions from the parent.  I believe we had it this way at
> one point, didn't we?
>
> Anyway I think this change didn't work out, and we should undo it
> while it's still remotely possible.  WDYT?
>
> --
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From david.lloyd at redhat.com  Fri May  4 17:11:07 2018
From: david.lloyd at redhat.com (David Lloyd)
Date: Fri, 4 May 2018 16:11:07 -0500
Subject: [wildfly-dev] Proposal to revert component-matrix change
In-Reply-To: <CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>
References: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
	<CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>
Message-ID: <CANghgrQ5Tv9iprCBtbcP-XjF7S9pFSp1WztRHYYg7h1MYpyNhw@mail.gmail.com>

I've created https://issues.jboss.org/browse/WFLY-10330 and
https://issues.jboss.org/browse/WFCORE-3803 to track this.

On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene at redhat.com> wrote:
> I agree. We can break the bom cycle a different way.
>
>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd at redhat.com> wrote:
>>
>> I propose we revert the component-matrix change.  This change is
>> ostensibly to help in the creation of a BOM for the client libraries
>> and other dependent projects; however, the cost has turned out to be
>> somewhat higher than expected.
>>
>> IntelliJ seems to be unable to cope with dependency changes in the
>> project due to the use of import from the root POM.  This means that
>> the entire project must be force-reimported from time to time to keep
>> dependencies up to date, and forgetting to do so can lead to
>> development issues and lost time.
>>
>> Also, I've observed that Maven itself does not always correctly
>> resolve versions anymore, when you're building from a submodule.  I
>> don't really know why this is the case but I suspect that it's due to
>> some algorithmic ambiguity when the dependency tree is not linear like
>> it used to be.
>>
>> I think that if we need to generate some BOM for use by external
>> projects, it should be done as a separate step and artifact which
>> acquires versions from the parent.  I believe we had it this way at
>> one point, didn't we?
>>
>> Anyway I think this change didn't work out, and we should undo it
>> while it's still remotely possible.  WDYT?
>>
>> --
>> - DML
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev



-- 
- DML

From kkhan at redhat.com  Sat May  5 05:25:31 2018
From: kkhan at redhat.com (Kabir Khan)
Date: Sat, 5 May 2018 10:25:31 +0100
Subject: [wildfly-dev] Proposal to revert component-matrix change
In-Reply-To: <CANghgrQ5Tv9iprCBtbcP-XjF7S9pFSp1WztRHYYg7h1MYpyNhw@mail.gmail.com>
References: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
	<CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>
	<CANghgrQ5Tv9iprCBtbcP-XjF7S9pFSp1WztRHYYg7h1MYpyNhw@mail.gmail.com>
Message-ID: <E44D4A57-C2A1-4B45-98AA-D90C56F82B24@redhat.com>

Perhaps https://github.com/jboss/bom-builder-maven-plugin can be used? I've not played with it

> On 4 May 2018, at 22:11, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> I've created https://issues.jboss.org/browse/WFLY-10330 and
> https://issues.jboss.org/browse/WFCORE-3803 to track this.
> 
> On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene at redhat.com> wrote:
>> I agree. We can break the bom cycle a different way.
>> 
>>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd at redhat.com> wrote:
>>> 
>>> I propose we revert the component-matrix change.  This change is
>>> ostensibly to help in the creation of a BOM for the client libraries
>>> and other dependent projects; however, the cost has turned out to be
>>> somewhat higher than expected.
>>> 
>>> IntelliJ seems to be unable to cope with dependency changes in the
>>> project due to the use of import from the root POM.  This means that
>>> the entire project must be force-reimported from time to time to keep
>>> dependencies up to date, and forgetting to do so can lead to
>>> development issues and lost time.
>>> 
>>> Also, I've observed that Maven itself does not always correctly
>>> resolve versions anymore, when you're building from a submodule.  I
>>> don't really know why this is the case but I suspect that it's due to
>>> some algorithmic ambiguity when the dependency tree is not linear like
>>> it used to be.
>>> 
>>> I think that if we need to generate some BOM for use by external
>>> projects, it should be done as a separate step and artifact which
>>> acquires versions from the parent.  I believe we had it this way at
>>> one point, didn't we?
>>> 
>>> Anyway I think this change didn't work out, and we should undo it
>>> while it's still remotely possible.  WDYT?
>>> 
>>> --
>>> - DML
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> 
> 
> -- 
> - DML
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev



From slaskawi at redhat.com  Sun May  6 19:10:17 2018
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Sun, 06 May 2018 23:10:17 +0000
Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan
 Openshift Template
In-Reply-To: <CALaezvVTZxFDo+auOALk3tjXC1nkTShZuZu5364GQFSNrcPFtg@mail.gmail.com>
References: <CAFm4XO1sd48hcd76PF6THjXpExzKoHC=GgU7BwEUnwRV8o=avw@mail.gmail.com>
	<CAA9R9O77sdZA3b=AXudPmBUrfZXYJXU+3+KGzeV7H=BJ=7PcNQ@mail.gmail.com>
	<CAFm4XO1Ld81pjqfvw7G+EXit+uYkkJKtzpi=fYvkh1Sr-hhofw@mail.gmail.com>
	<CAA9R9O6ZfZ3HzpOQs0dnNvrvGB0tPR_T9qZSvCh1aaKP3qjotw@mail.gmail.com>
	<CAFMDs3DFJZd5LkhVwhzdyTQ15VskgcRgCLiAgAc5rkCDwdpVhQ@mail.gmail.com>
	<CAA9R9O77t21M=D8bMoQp7HsvHMsTQO2J_+k_iKgKQucNLZWeMA@mail.gmail.com>
	<CALaezvUOXKEE87iTagAnE-Dnx2SYGefmGOTbVkih0R_X-HuUQQ@mail.gmail.com>
	<CAA9R9O6HJk+CAC7X4QG07zO3Wtq8=rVq9we5UCKUmywjVENZ2A@mail.gmail.com>
	<CALaezvVJLuv4OYqdKk73gNLPiUyE2h-FQtU5dF8xfc-7XFPaFg@mail.gmail.com>
	<CAA9R9O7rYHmN6zSk+oP43Je3a4DQBjZw_+Ox9RmG5HbH5WnBag@mail.gmail.com>
	<CALaezvVTZxFDo+auOALk3tjXC1nkTShZuZu5364GQFSNrcPFtg@mail.gmail.com>
Message-ID: <CAA9R9O4rb+VqbgTWppg0TK+_J9W=3xVrs+ac1gnO1MoCTXFoEw@mail.gmail.com>

Ok, so how about doing the same thing you suggested, but just more
explicitly - adding node-identifier="${jboss.node.name*:1*}". This way the
bare metal deployment should be happy (since the default is still 1) and we
wouldn't need to override it in Infinispan.

On Tue, May 1, 2018 at 10:09 AM Tom Jenkinson <tom.jenkinson at redhat.com>
wrote:

> I am not sure - the default should be "1" for the bare metal case so the
> warning is reliably triggered but the default can be the pod name for
> OpenShift templates that only allow a single instance of the application
> server - does that help?
>
> The file you looked to want to edit is shared by bare metal and other
> deployment environments so it would be confusing to set the default to
> jboss.node.name there IMO.
>
> On 1 May 2018 at 03:39, Sebastian Laskawiec <slaskawi at redhat.com> wrote:
>
>> Fair enough Tom. Thanks for explanation.
>>
>> One more request - would you guys be OK with me adding
>> a node-identifier="${jboss.node.name}" to the transaction subsystem
>> template [1]? This way we wouldn't need to copy it into Infinispan (since
>> we need to set it).
>>
>> [1]
>> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/resources/subsystem-templates/transactions.xml#L6
>>
>> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson <tom.jenkinson at redhat.com>
>> wrote:
>>
>>> On 18 April 2018 at 14:07, Sebastian Laskawiec <slaskawi at redhat.com>
>>> wrote:
>>>
>>>> Hey Tom,
>>>>
>>>> Comments inlined.
>>>>
>>>> Thanks,
>>>> Sebastian
>>>>
>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson <tom.jenkinson at redhat.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 16 April 2018 at 09:31, <> wrote:
>>>>>
>>>>>> Adding +WildFly Dev <wildfly-dev at lists.jboss.org> to the loop
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks for the explanation Rado.
>>>>>>
>>>>>> TL;DR: A while ago Sanne pointed out that we do not set
>>>>>> `node-identifier`
>>>>>> in transaction subsystem by default. The default value for the
>>>>>> `node-identifier` attribute it `1`. Not setting this attribute might
>>>>>> cause
>>>>>> problems in transaction recovery. Perhaps we could follow Rado's idea
>>>>>> and
>>>>>> set it to node name by default?
>>>>>>
>>>>> Indeed - it would cause serious data integrity problems if a
>>>>> non-unique node-identifier is used.
>>>>>
>>>>>> Some more comments inlined.
>>>>>>
>>>>>> Thanks,
>>>>>> Sebastian
>>>>>>
>>>>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar <rhusar at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>> > Hi Sebastian,
>>>>>> >
>>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec
>>>>>> > <slaskawi at redhat.com> wrote:
>>>>>> > > Hey Rado, Paul,
>>>>>> > >
>>>>>> > > I started looking into this issue and it turned out that WF
>>>>>> subsystem
>>>>>> > > template doesn't provide `node-identifier` attribute [1].
>>>>>> >
>>>>>> > I assume you mean that the default WildFly server profiles do not
>>>>>>
>>>>> > explicitly define the attribute. Right ? thus the value defaults in
>>>>>
>>>>>
>>>>>> > the model to "1"
>>>>>> >
>>>>>> >
>>>>>> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/subsystem/TransactionSubsystemRootResourceDefinition.java#L97
>>>>>> > which sole intention seems to be to log a warning on boot if the
>>>>>> value
>>>>>> > is unchanged.
>>>>>> > Why they decided on a constant that will be inherently not unique as
>>>>>> > opposed to defaulting to the node name (which we already require to
>>>>>> be
>>>>>> > unique) as clustering node name or undertow instance-id does, is
>>>>>> > unclear to me.
>>>>>> > Some context is on https://issues.jboss.org/browse/WFLY-1119.
>>>>>> >
>>>>>>
>>>>>> In OpenShift environment we could set it to `hostname`. This is
>>>>>> guaranteed
>>>>>> to be unique in whole OpenShift cluster.
>>>>>>
>>>>>>
>>>>>> We do this too in EAP images.
>>>>> To Rado's point, the default is "1" so we can print the warning to
>>>>> alert people they are misconfigured - it seems to be working :)
>>>>>
>>>>
>>>> This is the point. From my understanding, if we set it to node name
>>>> (instead of "1"), we could make it always work correctly. We could even
>>>> remove the code that emits the warning (since the node name needs to be
>>>> unique).
>>>>
>>>> To sum it up - if we decided to proceed this way, there would be no
>>>> requirement of setting the node-identifier at all.
>>>>
>>>
>>> For OpenShift you are right there is no requirement for someone to
>>> change the node-identifier from the podname and so that is why EAP images
>>> do that.
>>>
>>> For bare-metal it is different as there can be two servers on the same
>>> machine so they were configured to use the hostname as they node-identifier
>>> then if they were also connected to the same resource managers or the same
>>> object store they would interfere with each other.
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>> >
>>>>>
>>>>>
>>>>>> > > I'm not sure if you guys are the right people to ask, but is it
>>>>>> safe to
>>>>>> > > leave it set to default? Or shall I override our Infinispan
>>>>>> templates and
>>>>>> > > add this parameter (as I mentioned before, in OpenShift this I
>>>>>> wanted to
>>>>>> > set
>>>>>> > > it as Pod name trimmed to the last 23 chars since this is the
>>>>>> limit).
>>>>>>
>>>>> Putting a response to this in line - I am not certain who originally
>>>>> proposed this.
>>>>>
>>>>> You must use a globally unique node-identifier. If you are certain the
>>>>> last 23 characters guarantee that it would be valid - if there is a chance
>>>>> they are not unique it is not valid to trim.
>>>>>
>>>>
>>>> If that's not an issue, again, we could use the same limit as we have
>>>> for node name.
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>> >
>>>>>
>>>>>
>>>>>> > It is not safe to leave it set to "1" as that results in
>>>>>> inconsistent
>>>>>> > processing of transaction recovery.
>>>>>> > IIUC we already set it to the node name for both EAP and JDG
>>>>>> >
>>>>>> >
>>>>>> https://github.com/jboss-openshift/cct_module/blob/master/os-eap70-openshift/added/standalone-openshift.xml#L411
>>>>>> >
>>>>>> >
>>>>>> https://github.com/jboss-openshift/cct_module/blob/master/os-jdg7-conffiles/added/clustered-openshift.xml#L282
>>>>>>
>>>>> > which in turn defaults to the pod name ? so which profiles are we
>>>>>
>>>>>
>>>>>> > talking about here?
>>>>>> >
>>>>>>
>>>>>> Granted, we set it by default in CCT Modules. However in Infinispan
>>>>>> we just
>>>>>> grab provided transaction subsystem when rendering full configuration
>>>>>> from
>>>>>> featurepacks:
>>>>>>
>>>>>> https://github.com/infinispan/infinispan/blob/master/server/integration/feature-pack/src/main/resources/configuration/standalone/subsystems-cloud.xml#L19
>>>>>>
>>>>>> The default configuration XML doesn't contain the `node-identifier`
>>>>>> attribute. I can add it manually in the cloud.xml but I believe the
>>>>>> right
>>>>>> approach is to modify the transaction subsystem.
>>>>>>
>>>>>>
>>>>>> > Rado
>>>>>> >
>>>>>> > > Thanks,
>>>>>> > > Seb
>>>>>> > >
>>>>>> > > [1] usually set to node-identifier="${jboss.node.name}"
>>>>>> > >
>>>>>> > >
>>>>>>
>>>>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero <sanne at
>>>>>> infinispan.org>
>>>>>> > > wrote:
>>>>>> > >>
>>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec <slaskawi at
>>>>>> redhat.com>
>>>>>
>>>>>
>>>>>> > wrote:
>>>>>> > >> > Thanks for looking into it Sanne. Of course, we should add it
>>>>>> (it can
>>>>>> > be
>>>>>> > >> > set
>>>>>> > >> > to the same name as hostname since those are unique in
>>>>>> Kubernetes).
>>>>>> > >> >
>>>>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 for it.
>>>>>> > >> >
>>>>>> > >> > Thanks again!
>>>>>> > >> > Seb
>>>>>> > >>
>>>>>> > >> Thanks Sebastian!
>>>>>> > >>
>>>>>> > >> >
>>>>>>
>>>>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero <sanne at
>>>>>> infinispan.org>
>>>>>
>>>>>
>>>>>> > >> > wrote:
>>>>>> > >> >>
>>>>>> > >> >> Hi all,
>>>>>> > >> >>
>>>>>> > >> >> I've started to use the Infinispan Openshift Template and was
>>>>>> > browsing
>>>>>> > >> >> through the errors and warnings this produces.
>>>>>> > >> >>
>>>>>> > >> >> In particular I noticed "WFLYTX0013: Node identifier property
>>>>>> is set
>>>>>> > >> >> to the default value. Please make sure it is unique." being
>>>>>> produced
>>>>>> > >> >> by the transaction system.
>>>>>> > >> >>
>>>>>> > >> >> The node id is usually not needed for developer's convenience
>>>>>> and
>>>>>> > >> >> assuming there's a single node in "dev mode", yet clearly the
>>>>>> > >> >> Infinispan template is meant to work with multiple nodes
>>>>>> running so
>>>>>> > >> >> this warning seems concerning.
>>>>>> > >> >>
>>>>>> > >> >> I'm not sure what the impact is on the transaction manager so
>>>>>> I asked
>>>>>> > >> >> on the Narayana forums; Tom pointed me to some thourough
>>>>>> design
>>>>>> > >> >> documents and also suggested the EAP image does set the node
>>>>>> > >> >> identifier:
>>>>>> > >> >>  - https://developer.jboss.org/message/981702#981702
>>>>>> > >> >>
>>>>>> > >> >> WDYT? we probably want the Infinispan template to set this as
>>>>>> well,
>>>>>> > or
>>>>>> > >> >> silence the warning?
>>>>>> > >> >>
>>>>>> > >> >> Thanks,
>>>>>> > >> >> Sanne
>>>>>> > >> >> _______________________________________________
>>>>>> > >> >> infinispan-dev mailing list
>>>>>>
>>>>> > >> >> infinispan-dev at lists.jboss.org
>>>>>
>>>>>
>>>>>> > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>> > >> >
>>>>>> > >> >
>>>>>> > >> > _______________________________________________
>>>>>> > >> > infinispan-dev mailing list
>>>>>>
>>>>> > >> > infinispan-dev at lists.jboss.org
>>>>>
>>>>>
>>>>>> > >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>> > >> _______________________________________________
>>>>>> > >> infinispan-dev mailing list
>>>>>> > >> infinispan-dev at lists.jboss.org
>>>>>> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>> >
>>>>>> -------------- next part --------------
>>>>>> An HTML attachment was scrubbed...
>>>>>> URL:
>>>>>> http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180416/65962cf1/attachment-0001.html
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180506/3da806f2/attachment-0001.html 

From brian.stansberry at redhat.com  Mon May  7 17:08:14 2018
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Mon, 7 May 2018 16:08:14 -0500
Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan
 Openshift Template
In-Reply-To: <CAA9R9O4rb+VqbgTWppg0TK+_J9W=3xVrs+ac1gnO1MoCTXFoEw@mail.gmail.com>
References: <CAFm4XO1sd48hcd76PF6THjXpExzKoHC=GgU7BwEUnwRV8o=avw@mail.gmail.com>
	<CAA9R9O77sdZA3b=AXudPmBUrfZXYJXU+3+KGzeV7H=BJ=7PcNQ@mail.gmail.com>
	<CAFm4XO1Ld81pjqfvw7G+EXit+uYkkJKtzpi=fYvkh1Sr-hhofw@mail.gmail.com>
	<CAA9R9O6ZfZ3HzpOQs0dnNvrvGB0tPR_T9qZSvCh1aaKP3qjotw@mail.gmail.com>
	<CAFMDs3DFJZd5LkhVwhzdyTQ15VskgcRgCLiAgAc5rkCDwdpVhQ@mail.gmail.com>
	<CAA9R9O77t21M=D8bMoQp7HsvHMsTQO2J_+k_iKgKQucNLZWeMA@mail.gmail.com>
	<CALaezvUOXKEE87iTagAnE-Dnx2SYGefmGOTbVkih0R_X-HuUQQ@mail.gmail.com>
	<CAA9R9O6HJk+CAC7X4QG07zO3Wtq8=rVq9we5UCKUmywjVENZ2A@mail.gmail.com>
	<CALaezvVJLuv4OYqdKk73gNLPiUyE2h-FQtU5dF8xfc-7XFPaFg@mail.gmail.com>
	<CAA9R9O7rYHmN6zSk+oP43Je3a4DQBjZw_+Ox9RmG5HbH5WnBag@mail.gmail.com>
	<CALaezvVTZxFDo+auOALk3tjXC1nkTShZuZu5364GQFSNrcPFtg@mail.gmail.com>
	<CAA9R9O4rb+VqbgTWppg0TK+_J9W=3xVrs+ac1gnO1MoCTXFoEw@mail.gmail.com>
Message-ID: <CAPhbRDaTN4T3KvPud8Rk45m-b_C=1KhasahO4_uJqqBz1f_=Vw@mail.gmail.com>

If it's not already set, WildFly sets the system property jboss.node.name
at the very beginning of server boot, so ${jboss.node.name*:1*} would not
resolve to 1.

On Sun, May 6, 2018 at 6:10 PM, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Ok, so how about doing the same thing you suggested, but just more
> explicitly - adding node-identifier="${jboss.node.name*:1*}". This way
> the bare metal deployment should be happy (since the default is still 1)
> and we wouldn't need to override it in Infinispan.
>
> On Tue, May 1, 2018 at 10:09 AM Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
>
>> I am not sure - the default should be "1" for the bare metal case so the
>> warning is reliably triggered but the default can be the pod name for
>> OpenShift templates that only allow a single instance of the application
>> server - does that help?
>>
>> The file you looked to want to edit is shared by bare metal and other
>> deployment environments so it would be confusing to set the default to
>> jboss.node.name there IMO.
>>
>> On 1 May 2018 at 03:39, Sebastian Laskawiec <slaskawi at redhat.com> wrote:
>>
>>> Fair enough Tom. Thanks for explanation.
>>>
>>> One more request - would you guys be OK with me adding
>>> a node-identifier="${jboss.node.name}" to the transaction subsystem
>>> template [1]? This way we wouldn't need to copy it into Infinispan (since
>>> we need to set it).
>>>
>>> [1] https://github.com/wildfly/wildfly/blob/master/
>>> transactions/src/main/resources/subsystem-templates/transactions.xml#L6
>>>
>>> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson <tom.jenkinson at redhat.com>
>>> wrote:
>>>
>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec <slaskawi at redhat.com>
>>>> wrote:
>>>>
>>>>> Hey Tom,
>>>>>
>>>>> Comments inlined.
>>>>>
>>>>> Thanks,
>>>>> Sebastian
>>>>>
>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson <
>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 16 April 2018 at 09:31, <> wrote:
>>>>>>
>>>>>>> Adding +WildFly Dev <wildfly-dev at lists.jboss.org> to the loop
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Thanks for the explanation Rado.
>>>>>>>
>>>>>>> TL;DR: A while ago Sanne pointed out that we do not set
>>>>>>> `node-identifier`
>>>>>>> in transaction subsystem by default. The default value for the
>>>>>>> `node-identifier` attribute it `1`. Not setting this attribute might
>>>>>>> cause
>>>>>>> problems in transaction recovery. Perhaps we could follow Rado's
>>>>>>> idea and
>>>>>>> set it to node name by default?
>>>>>>>
>>>>>> Indeed - it would cause serious data integrity problems if a
>>>>>> non-unique node-identifier is used.
>>>>>>
>>>>>>> Some more comments inlined.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Sebastian
>>>>>>>
>>>>>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar <rhusar at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> > Hi Sebastian,
>>>>>>> >
>>>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec
>>>>>>> > <slaskawi at redhat.com> wrote:
>>>>>>> > > Hey Rado, Paul,
>>>>>>> > >
>>>>>>> > > I started looking into this issue and it turned out that WF
>>>>>>> subsystem
>>>>>>> > > template doesn't provide `node-identifier` attribute [1].
>>>>>>> >
>>>>>>> > I assume you mean that the default WildFly server profiles do not
>>>>>>>
>>>>>> > explicitly define the attribute. Right ? thus the value defaults in
>>>>>>
>>>>>>
>>>>>>> > the model to "1"
>>>>>>> >
>>>>>>> > https://github.com/wildfly/wildfly/blob/master/
>>>>>>> transactions/src/main/java/org/jboss/as/txn/subsystem/
>>>>>>> TransactionSubsystemRootResourceDefinition.java#L97
>>>>>>> > which sole intention seems to be to log a warning on boot if the
>>>>>>> value
>>>>>>> > is unchanged.
>>>>>>> > Why they decided on a constant that will be inherently not unique
>>>>>>> as
>>>>>>> > opposed to defaulting to the node name (which we already require
>>>>>>> to be
>>>>>>> > unique) as clustering node name or undertow instance-id does, is
>>>>>>> > unclear to me.
>>>>>>> > Some context is on https://issues.jboss.org/browse/WFLY-1119.
>>>>>>> >
>>>>>>>
>>>>>>> In OpenShift environment we could set it to `hostname`. This is
>>>>>>> guaranteed
>>>>>>> to be unique in whole OpenShift cluster.
>>>>>>>
>>>>>>>
>>>>>>> We do this too in EAP images.
>>>>>> To Rado's point, the default is "1" so we can print the warning to
>>>>>> alert people they are misconfigured - it seems to be working :)
>>>>>>
>>>>>
>>>>> This is the point. From my understanding, if we set it to node name
>>>>> (instead of "1"), we could make it always work correctly. We could even
>>>>> remove the code that emits the warning (since the node name needs to be
>>>>> unique).
>>>>>
>>>>> To sum it up - if we decided to proceed this way, there would be no
>>>>> requirement of setting the node-identifier at all.
>>>>>
>>>>
>>>> For OpenShift you are right there is no requirement for someone to
>>>> change the node-identifier from the podname and so that is why EAP images
>>>> do that.
>>>>
>>>> For bare-metal it is different as there can be two servers on the same
>>>> machine so they were configured to use the hostname as they node-identifier
>>>> then if they were also connected to the same resource managers or the same
>>>> object store they would interfere with each other.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>> >
>>>>>>
>>>>>>
>>>>>>> > > I'm not sure if you guys are the right people to ask, but is it
>>>>>>> safe to
>>>>>>> > > leave it set to default? Or shall I override our Infinispan
>>>>>>> templates and
>>>>>>> > > add this parameter (as I mentioned before, in OpenShift this I
>>>>>>> wanted to
>>>>>>> > set
>>>>>>> > > it as Pod name trimmed to the last 23 chars since this is the
>>>>>>> limit).
>>>>>>>
>>>>>> Putting a response to this in line - I am not certain who originally
>>>>>> proposed this.
>>>>>>
>>>>>> You must use a globally unique node-identifier. If you are certain
>>>>>> the last 23 characters guarantee that it would be valid - if there is a
>>>>>> chance they are not unique it is not valid to trim.
>>>>>>
>>>>>
>>>>> If that's not an issue, again, we could use the same limit as we have
>>>>> for node name.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> >
>>>>>>
>>>>>>
>>>>>>> > It is not safe to leave it set to "1" as that results in
>>>>>>> inconsistent
>>>>>>> > processing of transaction recovery.
>>>>>>> > IIUC we already set it to the node name for both EAP and JDG
>>>>>>> >
>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/
>>>>>>> master/os-eap70-openshift/added/standalone-openshift.xml#L411
>>>>>>> >
>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/
>>>>>>> master/os-jdg7-conffiles/added/clustered-openshift.xml#L282
>>>>>>>
>>>>>> > which in turn defaults to the pod name ? so which profiles are we
>>>>>>
>>>>>>
>>>>>>> > talking about here?
>>>>>>> >
>>>>>>>
>>>>>>> Granted, we set it by default in CCT Modules. However in Infinispan
>>>>>>> we just
>>>>>>> grab provided transaction subsystem when rendering full
>>>>>>> configuration from
>>>>>>> featurepacks:
>>>>>>> https://github.com/infinispan/infinispan/blob/master/server/
>>>>>>> integration/feature-pack/src/main/resources/configuration/
>>>>>>> standalone/subsystems-cloud.xml#L19
>>>>>>>
>>>>>>> The default configuration XML doesn't contain the `node-identifier`
>>>>>>> attribute. I can add it manually in the cloud.xml but I believe the
>>>>>>> right
>>>>>>> approach is to modify the transaction subsystem.
>>>>>>>
>>>>>>>
>>>>>>> > Rado
>>>>>>> >
>>>>>>> > > Thanks,
>>>>>>> > > Seb
>>>>>>> > >
>>>>>>> > > [1] usually set to node-identifier="${jboss.node.name}"
>>>>>>> > >
>>>>>>> > >
>>>>>>>
>>>>>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero <sanne at
>>>>>>> infinispan.org>
>>>>>>> > > wrote:
>>>>>>> > >>
>>>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec <slaskawi at
>>>>>>> redhat.com>
>>>>>>
>>>>>>
>>>>>>> > wrote:
>>>>>>> > >> > Thanks for looking into it Sanne. Of course, we should add it
>>>>>>> (it can
>>>>>>> > be
>>>>>>> > >> > set
>>>>>>> > >> > to the same name as hostname since those are unique in
>>>>>>> Kubernetes).
>>>>>>> > >> >
>>>>>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 for it.
>>>>>>> > >> >
>>>>>>> > >> > Thanks again!
>>>>>>> > >> > Seb
>>>>>>> > >>
>>>>>>> > >> Thanks Sebastian!
>>>>>>> > >>
>>>>>>> > >> >
>>>>>>>
>>>>>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero <sanne at
>>>>>>> infinispan.org>
>>>>>>
>>>>>>
>>>>>>> > >> > wrote:
>>>>>>> > >> >>
>>>>>>> > >> >> Hi all,
>>>>>>> > >> >>
>>>>>>> > >> >> I've started to use the Infinispan Openshift Template and was
>>>>>>> > browsing
>>>>>>> > >> >> through the errors and warnings this produces.
>>>>>>> > >> >>
>>>>>>> > >> >> In particular I noticed "WFLYTX0013: Node identifier
>>>>>>> property is set
>>>>>>> > >> >> to the default value. Please make sure it is unique." being
>>>>>>> produced
>>>>>>> > >> >> by the transaction system.
>>>>>>> > >> >>
>>>>>>> > >> >> The node id is usually not needed for developer's
>>>>>>> convenience and
>>>>>>> > >> >> assuming there's a single node in "dev mode", yet clearly the
>>>>>>> > >> >> Infinispan template is meant to work with multiple nodes
>>>>>>> running so
>>>>>>> > >> >> this warning seems concerning.
>>>>>>> > >> >>
>>>>>>> > >> >> I'm not sure what the impact is on the transaction manager
>>>>>>> so I asked
>>>>>>> > >> >> on the Narayana forums; Tom pointed me to some thourough
>>>>>>> design
>>>>>>> > >> >> documents and also suggested the EAP image does set the node
>>>>>>> > >> >> identifier:
>>>>>>> > >> >>  - https://developer.jboss.org/message/981702#981702
>>>>>>> > >> >>
>>>>>>> > >> >> WDYT? we probably want the Infinispan template to set this
>>>>>>> as well,
>>>>>>> > or
>>>>>>> > >> >> silence the warning?
>>>>>>> > >> >>
>>>>>>> > >> >> Thanks,
>>>>>>> > >> >> Sanne
>>>>>>> > >> >> _______________________________________________
>>>>>>> > >> >> infinispan-dev mailing list
>>>>>>>
>>>>>> > >> >> infinispan-dev at lists.jboss.org
>>>>>>
>>>>>>
>>>>>>> > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>> > >> >
>>>>>>> > >> >
>>>>>>> > >> > _______________________________________________
>>>>>>> > >> > infinispan-dev mailing list
>>>>>>>
>>>>>> > >> > infinispan-dev at lists.jboss.org
>>>>>>
>>>>>>
>>>>>>> > >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>> > >> _______________________________________________
>>>>>>> > >> infinispan-dev mailing list
>>>>>>> > >> infinispan-dev at lists.jboss.org
>>>>>>> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>> >
>>>>>>> -------------- next part --------------
>>>>>>> An HTML attachment was scrubbed...
>>>>>>> URL: http://lists.jboss.org/pipermail/wildfly-dev/
>>>>>>> attachments/20180416/65962cf1/attachment-0001.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>
> _______________________________________________
> 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/20180507/2a70ac8a/attachment-0001.html 

From rory.odonnell at oracle.com  Tue May  8 04:08:23 2018
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Tue, 8 May 2018 09:08:23 +0100
Subject: [wildfly-dev] JDK 11 Early Access build 12 available
Message-ID: <25fb290b-1180-746c-bcda-e141b90d83a7@oracle.com>


Hi Jason/Tomaz,

**JDK 11 EA build 12 , *****under both the GPL and Oracle EA licenses, 
is now available at **http://jdk.java.net/11**. **
*

  * Newly approved Schedule, status & features
      o http://openjdk.java.net/projects/jdk/11/
  * Release Notes:
      o http://jdk.java.net/11/release-notes
  * Summary of changes
      o https://download.java.net/java/early_access/jdk11/12/jdk-11+12.html

*Notable changes in JDK 11 EA builds since last email:*

  * Build 11 - see Release Notes for details.
      o JDK-8201315 : SelectableChannel.register may be invoked while a
        selection operation is in progress
  * Build 10 - see Release Notes for details.
      o JDK-8200149 : Removal of "com.sun.awt.AWTUtilities" class
      o JDK-8189997 (not public) :? Enhanced KeyStore Mechanisms
      o JDK-8175075 (not public) : 3DES Cipher Suites Disabled
  * Build 9: - see Release Notes for details.
      o JDK-8200152 : KerberosString uses UTF-8 encoding by default
      o JDK-8200458 : Readiness information previously recorded in
        SelectionKey ready set not preserved

**


*Draft JEP: Deprecate pack200, unpack200 tools and related APIs. [1]
*
This draft JEP [2] proposes to deprecate the pack200 APIs and tools in 
the JDK. As outlined in the JEP, the usefulness of this technology
have diminishing returns, the components using them are being removed 
and connectivity speeds have improved by leaps and bounds,
since its inception.? Feedback appreciated via 
http://mail.openjdk.java.net/pipermail/jdk-dev

Regards,
Rory

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-April/001074.html
[2] https://bugs.openjdk.java.net/browse/JDK-8200752

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/20180508/2cb77dd2/attachment.html 

From tom.jenkinson at redhat.com  Tue May  8 04:28:17 2018
From: tom.jenkinson at redhat.com (Tom Jenkinson)
Date: Tue, 8 May 2018 09:28:17 +0100
Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan
 Openshift Template
In-Reply-To: <CAPhbRDaTN4T3KvPud8Rk45m-b_C=1KhasahO4_uJqqBz1f_=Vw@mail.gmail.com>
References: <CAFm4XO1sd48hcd76PF6THjXpExzKoHC=GgU7BwEUnwRV8o=avw@mail.gmail.com>
	<CAA9R9O77sdZA3b=AXudPmBUrfZXYJXU+3+KGzeV7H=BJ=7PcNQ@mail.gmail.com>
	<CAFm4XO1Ld81pjqfvw7G+EXit+uYkkJKtzpi=fYvkh1Sr-hhofw@mail.gmail.com>
	<CAA9R9O6ZfZ3HzpOQs0dnNvrvGB0tPR_T9qZSvCh1aaKP3qjotw@mail.gmail.com>
	<CAFMDs3DFJZd5LkhVwhzdyTQ15VskgcRgCLiAgAc5rkCDwdpVhQ@mail.gmail.com>
	<CAA9R9O77t21M=D8bMoQp7HsvHMsTQO2J_+k_iKgKQucNLZWeMA@mail.gmail.com>
	<CALaezvUOXKEE87iTagAnE-Dnx2SYGefmGOTbVkih0R_X-HuUQQ@mail.gmail.com>
	<CAA9R9O6HJk+CAC7X4QG07zO3Wtq8=rVq9we5UCKUmywjVENZ2A@mail.gmail.com>
	<CALaezvVJLuv4OYqdKk73gNLPiUyE2h-FQtU5dF8xfc-7XFPaFg@mail.gmail.com>
	<CAA9R9O7rYHmN6zSk+oP43Je3a4DQBjZw_+Ox9RmG5HbH5WnBag@mail.gmail.com>
	<CALaezvVTZxFDo+auOALk3tjXC1nkTShZuZu5364GQFSNrcPFtg@mail.gmail.com>
	<CAA9R9O4rb+VqbgTWppg0TK+_J9W=3xVrs+ac1gnO1MoCTXFoEw@mail.gmail.com>
	<CAPhbRDaTN4T3KvPud8Rk45m-b_C=1KhasahO4_uJqqBz1f_=Vw@mail.gmail.com>
Message-ID: <CALaezvUUXYwrhPRNXF-CVQgv7EEYVFW3YrTs=5wabBN9rtsyBg@mail.gmail.com>

Thanks for confirming Brian.

Perhaps we could set it to:
node-identifier="${jboss.tx.node.id:1}"
(a bit like
https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.1/jts)

Sebastian could set -Djboss.tx.node.id during startup in a script?



On 7 May 2018 at 22:08, Brian Stansberry <brian.stansberry at redhat.com>
wrote:

> If it's not already set, WildFly sets the system property jboss.node.name
> at the very beginning of server boot, so ${jboss.node.name*:1*} would not
> resolve to 1.
>
> On Sun, May 6, 2018 at 6:10 PM, Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>> Ok, so how about doing the same thing you suggested, but just more
>> explicitly - adding node-identifier="${jboss.node.name*:1*}". This way
>> the bare metal deployment should be happy (since the default is still 1)
>> and we wouldn't need to override it in Infinispan.
>>
>> On Tue, May 1, 2018 at 10:09 AM Tom Jenkinson <tom.jenkinson at redhat.com>
>> wrote:
>>
>>> I am not sure - the default should be "1" for the bare metal case so the
>>> warning is reliably triggered but the default can be the pod name for
>>> OpenShift templates that only allow a single instance of the application
>>> server - does that help?
>>>
>>> The file you looked to want to edit is shared by bare metal and other
>>> deployment environments so it would be confusing to set the default to
>>> jboss.node.name there IMO.
>>>
>>> On 1 May 2018 at 03:39, Sebastian Laskawiec <slaskawi at redhat.com> wrote:
>>>
>>>> Fair enough Tom. Thanks for explanation.
>>>>
>>>> One more request - would you guys be OK with me adding
>>>> a node-identifier="${jboss.node.name}" to the transaction subsystem
>>>> template [1]? This way we wouldn't need to copy it into Infinispan (since
>>>> we need to set it).
>>>>
>>>> [1] https://github.com/wildfly/wildfly/blob/master/transacti
>>>> ons/src/main/resources/subsystem-templates/transactions.xml#L6
>>>>
>>>> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson <tom.jenkinson at redhat.com>
>>>> wrote:
>>>>
>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec <slaskawi at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Hey Tom,
>>>>>>
>>>>>> Comments inlined.
>>>>>>
>>>>>> Thanks,
>>>>>> Sebastian
>>>>>>
>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson <
>>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 16 April 2018 at 09:31, <> wrote:
>>>>>>>
>>>>>>>> Adding +WildFly Dev <wildfly-dev at lists.jboss.org> to the loop
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks for the explanation Rado.
>>>>>>>>
>>>>>>>> TL;DR: A while ago Sanne pointed out that we do not set
>>>>>>>> `node-identifier`
>>>>>>>> in transaction subsystem by default. The default value for the
>>>>>>>> `node-identifier` attribute it `1`. Not setting this attribute
>>>>>>>> might cause
>>>>>>>> problems in transaction recovery. Perhaps we could follow Rado's
>>>>>>>> idea and
>>>>>>>> set it to node name by default?
>>>>>>>>
>>>>>>> Indeed - it would cause serious data integrity problems if a
>>>>>>> non-unique node-identifier is used.
>>>>>>>
>>>>>>>> Some more comments inlined.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Sebastian
>>>>>>>>
>>>>>>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar <rhusar at
>>>>>>>> redhat.com> wrote:
>>>>>>>>
>>>>>>>> > Hi Sebastian,
>>>>>>>> >
>>>>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec
>>>>>>>> > <slaskawi at redhat.com> wrote:
>>>>>>>> > > Hey Rado, Paul,
>>>>>>>> > >
>>>>>>>> > > I started looking into this issue and it turned out that WF
>>>>>>>> subsystem
>>>>>>>> > > template doesn't provide `node-identifier` attribute [1].
>>>>>>>> >
>>>>>>>> > I assume you mean that the default WildFly server profiles do not
>>>>>>>>
>>>>>>> > explicitly define the attribute. Right ? thus the value defaults in
>>>>>>>
>>>>>>>
>>>>>>>> > the model to "1"
>>>>>>>> >
>>>>>>>> > https://github.com/wildfly/wildfly/blob/master/transactions/
>>>>>>>> src/main/java/org/jboss/as/txn/subsystem/TransactionSubsy
>>>>>>>> stemRootResourceDefinition.java#L97
>>>>>>>> > which sole intention seems to be to log a warning on boot if the
>>>>>>>> value
>>>>>>>> > is unchanged.
>>>>>>>> > Why they decided on a constant that will be inherently not unique
>>>>>>>> as
>>>>>>>> > opposed to defaulting to the node name (which we already require
>>>>>>>> to be
>>>>>>>> > unique) as clustering node name or undertow instance-id does, is
>>>>>>>> > unclear to me.
>>>>>>>> > Some context is on https://issues.jboss.org/browse/WFLY-1119.
>>>>>>>> >
>>>>>>>>
>>>>>>>> In OpenShift environment we could set it to `hostname`. This is
>>>>>>>> guaranteed
>>>>>>>> to be unique in whole OpenShift cluster.
>>>>>>>>
>>>>>>>>
>>>>>>>> We do this too in EAP images.
>>>>>>> To Rado's point, the default is "1" so we can print the warning to
>>>>>>> alert people they are misconfigured - it seems to be working :)
>>>>>>>
>>>>>>
>>>>>> This is the point. From my understanding, if we set it to node name
>>>>>> (instead of "1"), we could make it always work correctly. We could even
>>>>>> remove the code that emits the warning (since the node name needs to be
>>>>>> unique).
>>>>>>
>>>>>> To sum it up - if we decided to proceed this way, there would be no
>>>>>> requirement of setting the node-identifier at all.
>>>>>>
>>>>>
>>>>> For OpenShift you are right there is no requirement for someone to
>>>>> change the node-identifier from the podname and so that is why EAP images
>>>>> do that.
>>>>>
>>>>> For bare-metal it is different as there can be two servers on the same
>>>>> machine so they were configured to use the hostname as they node-identifier
>>>>> then if they were also connected to the same resource managers or the same
>>>>> object store they would interfere with each other.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>> > > I'm not sure if you guys are the right people to ask, but is it
>>>>>>>> safe to
>>>>>>>> > > leave it set to default? Or shall I override our Infinispan
>>>>>>>> templates and
>>>>>>>> > > add this parameter (as I mentioned before, in OpenShift this I
>>>>>>>> wanted to
>>>>>>>> > set
>>>>>>>> > > it as Pod name trimmed to the last 23 chars since this is the
>>>>>>>> limit).
>>>>>>>>
>>>>>>> Putting a response to this in line - I am not certain who originally
>>>>>>> proposed this.
>>>>>>>
>>>>>>> You must use a globally unique node-identifier. If you are certain
>>>>>>> the last 23 characters guarantee that it would be valid - if there is a
>>>>>>> chance they are not unique it is not valid to trim.
>>>>>>>
>>>>>>
>>>>>> If that's not an issue, again, we could use the same limit as we have
>>>>>> for node name.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>> > It is not safe to leave it set to "1" as that results in
>>>>>>>> inconsistent
>>>>>>>> > processing of transaction recovery.
>>>>>>>> > IIUC we already set it to the node name for both EAP and JDG
>>>>>>>> >
>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/master/
>>>>>>>> os-eap70-openshift/added/standalone-openshift.xml#L411
>>>>>>>> >
>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/master/
>>>>>>>> os-jdg7-conffiles/added/clustered-openshift.xml#L282
>>>>>>>>
>>>>>>> > which in turn defaults to the pod name ? so which profiles are we
>>>>>>>
>>>>>>>
>>>>>>>> > talking about here?
>>>>>>>> >
>>>>>>>>
>>>>>>>> Granted, we set it by default in CCT Modules. However in Infinispan
>>>>>>>> we just
>>>>>>>> grab provided transaction subsystem when rendering full
>>>>>>>> configuration from
>>>>>>>> featurepacks:
>>>>>>>> https://github.com/infinispan/infinispan/blob/master/server/
>>>>>>>> integration/feature-pack/src/main/resources/configuration/st
>>>>>>>> andalone/subsystems-cloud.xml#L19
>>>>>>>>
>>>>>>>> The default configuration XML doesn't contain the `node-identifier`
>>>>>>>> attribute. I can add it manually in the cloud.xml but I believe the
>>>>>>>> right
>>>>>>>> approach is to modify the transaction subsystem.
>>>>>>>>
>>>>>>>>
>>>>>>>> > Rado
>>>>>>>> >
>>>>>>>> > > Thanks,
>>>>>>>> > > Seb
>>>>>>>> > >
>>>>>>>> > > [1] usually set to node-identifier="${jboss.node.name}"
>>>>>>>> > >
>>>>>>>> > >
>>>>>>>>
>>>>>>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero <sanne at
>>>>>>>> infinispan.org>
>>>>>>>> > > wrote:
>>>>>>>> > >>
>>>>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec <slaskawi at
>>>>>>>> redhat.com>
>>>>>>>
>>>>>>>
>>>>>>>> > wrote:
>>>>>>>> > >> > Thanks for looking into it Sanne. Of course, we should add
>>>>>>>> it (it can
>>>>>>>> > be
>>>>>>>> > >> > set
>>>>>>>> > >> > to the same name as hostname since those are unique in
>>>>>>>> Kubernetes).
>>>>>>>> > >> >
>>>>>>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 for it.
>>>>>>>> > >> >
>>>>>>>> > >> > Thanks again!
>>>>>>>> > >> > Seb
>>>>>>>> > >>
>>>>>>>> > >> Thanks Sebastian!
>>>>>>>> > >>
>>>>>>>> > >> >
>>>>>>>>
>>>>>>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero <sanne at
>>>>>>>> infinispan.org>
>>>>>>>
>>>>>>>
>>>>>>>> > >> > wrote:
>>>>>>>> > >> >>
>>>>>>>> > >> >> Hi all,
>>>>>>>> > >> >>
>>>>>>>> > >> >> I've started to use the Infinispan Openshift Template and
>>>>>>>> was
>>>>>>>> > browsing
>>>>>>>> > >> >> through the errors and warnings this produces.
>>>>>>>> > >> >>
>>>>>>>> > >> >> In particular I noticed "WFLYTX0013: Node identifier
>>>>>>>> property is set
>>>>>>>> > >> >> to the default value. Please make sure it is unique." being
>>>>>>>> produced
>>>>>>>> > >> >> by the transaction system.
>>>>>>>> > >> >>
>>>>>>>> > >> >> The node id is usually not needed for developer's
>>>>>>>> convenience and
>>>>>>>> > >> >> assuming there's a single node in "dev mode", yet clearly
>>>>>>>> the
>>>>>>>> > >> >> Infinispan template is meant to work with multiple nodes
>>>>>>>> running so
>>>>>>>> > >> >> this warning seems concerning.
>>>>>>>> > >> >>
>>>>>>>> > >> >> I'm not sure what the impact is on the transaction manager
>>>>>>>> so I asked
>>>>>>>> > >> >> on the Narayana forums; Tom pointed me to some thourough
>>>>>>>> design
>>>>>>>> > >> >> documents and also suggested the EAP image does set the node
>>>>>>>> > >> >> identifier:
>>>>>>>> > >> >>  - https://developer.jboss.org/message/981702#981702
>>>>>>>> > >> >>
>>>>>>>> > >> >> WDYT? we probably want the Infinispan template to set this
>>>>>>>> as well,
>>>>>>>> > or
>>>>>>>> > >> >> silence the warning?
>>>>>>>> > >> >>
>>>>>>>> > >> >> Thanks,
>>>>>>>> > >> >> Sanne
>>>>>>>> > >> >> _______________________________________________
>>>>>>>> > >> >> infinispan-dev mailing list
>>>>>>>>
>>>>>>> > >> >> infinispan-dev at lists.jboss.org
>>>>>>>
>>>>>>>
>>>>>>>> > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>> > >> >
>>>>>>>> > >> >
>>>>>>>> > >> > _______________________________________________
>>>>>>>> > >> > infinispan-dev mailing list
>>>>>>>>
>>>>>>> > >> > infinispan-dev at lists.jboss.org
>>>>>>>
>>>>>>>
>>>>>>>> > >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>> > >> _______________________________________________
>>>>>>>> > >> infinispan-dev mailing list
>>>>>>>> > >> infinispan-dev at lists.jboss.org
>>>>>>>> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>> >
>>>>>>>> -------------- next part --------------
>>>>>>>> An HTML attachment was scrubbed...
>>>>>>>> URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/
>>>>>>>> 20180416/65962cf1/attachment-0001.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>
>> _______________________________________________
>> 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/20180508/e33b2b6d/attachment-0001.html 

From rsvoboda at redhat.com  Tue May  8 11:06:12 2018
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Tue, 8 May 2018 17:06:12 +0200
Subject: [wildfly-dev] Proposal to revert component-matrix change
In-Reply-To: <E44D4A57-C2A1-4B45-98AA-D90C56F82B24@redhat.com>
References: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
	<CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>
	<CANghgrQ5Tv9iprCBtbcP-XjF7S9pFSp1WztRHYYg7h1MYpyNhw@mail.gmail.com>
	<E44D4A57-C2A1-4B45-98AA-D90C56F82B24@redhat.com>
Message-ID: <CACa2xU8VE4xez2Ui5zVgtOV2UrPt35bvGpAbhPRTGi9RH_+xpQ@mail.gmail.com>

Tomaz mentioned Quickstarts as one of the reasons to have BOMs in WF and
WF-CORE.

Eduardo should confirm that revert is fine for QS.

Rostislav

On Sat, May 5, 2018 at 11:25 AM, Kabir Khan <kkhan at redhat.com> wrote:

> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be used?
> I've not played with it
>
> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd at redhat.com> wrote:
> >
> > I've created https://issues.jboss.org/browse/WFLY-10330 and
> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
> >
> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene at redhat.com>
> wrote:
> >> I agree. We can break the bom cycle a different way.
> >>
> >>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd at redhat.com>
> wrote:
> >>>
> >>> I propose we revert the component-matrix change.  This change is
> >>> ostensibly to help in the creation of a BOM for the client libraries
> >>> and other dependent projects; however, the cost has turned out to be
> >>> somewhat higher than expected.
> >>>
> >>> IntelliJ seems to be unable to cope with dependency changes in the
> >>> project due to the use of import from the root POM.  This means that
> >>> the entire project must be force-reimported from time to time to keep
> >>> dependencies up to date, and forgetting to do so can lead to
> >>> development issues and lost time.
> >>>
> >>> Also, I've observed that Maven itself does not always correctly
> >>> resolve versions anymore, when you're building from a submodule.  I
> >>> don't really know why this is the case but I suspect that it's due to
> >>> some algorithmic ambiguity when the dependency tree is not linear like
> >>> it used to be.
> >>>
> >>> I think that if we need to generate some BOM for use by external
> >>> projects, it should be done as a separate step and artifact which
> >>> acquires versions from the parent.  I believe we had it this way at
> >>> one point, didn't we?
> >>>
> >>> Anyway I think this change didn't work out, and we should undo it
> >>> while it's still remotely possible.  WDYT?
> >>>
> >>> --
> >>> - DML
> >>> _______________________________________________
> >>> wildfly-dev mailing list
> >>> wildfly-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
> >
> > --
> > - DML
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180508/c9d50239/attachment.html 

From david.lloyd at redhat.com  Tue May  8 11:08:34 2018
From: david.lloyd at redhat.com (David Lloyd)
Date: Tue, 8 May 2018 10:08:34 -0500
Subject: [wildfly-dev] Proposal to revert component-matrix change
In-Reply-To: <CACa2xU8VE4xez2Ui5zVgtOV2UrPt35bvGpAbhPRTGi9RH_+xpQ@mail.gmail.com>
References: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
	<CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>
	<CANghgrQ5Tv9iprCBtbcP-XjF7S9pFSp1WztRHYYg7h1MYpyNhw@mail.gmail.com>
	<E44D4A57-C2A1-4B45-98AA-D90C56F82B24@redhat.com>
	<CACa2xU8VE4xez2Ui5zVgtOV2UrPt35bvGpAbhPRTGi9RH_+xpQ@mail.gmail.com>
Message-ID: <CANghgrTNBfqk3ZNkz5roeBUw2ay9j1zTNbRjmJ7ADGfiz9zz+Q@mail.gmail.com>

We can still create BOMs in WF and WFCORE.  We would just have to do
so using a plugin or something similar.

On Tue, May 8, 2018 at 10:06 AM, Rostislav Svoboda <rsvoboda at redhat.com> wrote:
> Tomaz mentioned Quickstarts as one of the reasons to have BOMs in WF and
> WF-CORE.
>
> Eduardo should confirm that revert is fine for QS.
>
> Rostislav
>
> On Sat, May 5, 2018 at 11:25 AM, Kabir Khan <kkhan at redhat.com> wrote:
>>
>> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be used?
>> I've not played with it
>>
>> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd at redhat.com> wrote:
>> >
>> > I've created https://issues.jboss.org/browse/WFLY-10330 and
>> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
>> >
>> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene at redhat.com>
>> > wrote:
>> >> I agree. We can break the bom cycle a different way.
>> >>
>> >>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd at redhat.com>
>> >>> wrote:
>> >>>
>> >>> I propose we revert the component-matrix change.  This change is
>> >>> ostensibly to help in the creation of a BOM for the client libraries
>> >>> and other dependent projects; however, the cost has turned out to be
>> >>> somewhat higher than expected.
>> >>>
>> >>> IntelliJ seems to be unable to cope with dependency changes in the
>> >>> project due to the use of import from the root POM.  This means that
>> >>> the entire project must be force-reimported from time to time to keep
>> >>> dependencies up to date, and forgetting to do so can lead to
>> >>> development issues and lost time.
>> >>>
>> >>> Also, I've observed that Maven itself does not always correctly
>> >>> resolve versions anymore, when you're building from a submodule.  I
>> >>> don't really know why this is the case but I suspect that it's due to
>> >>> some algorithmic ambiguity when the dependency tree is not linear like
>> >>> it used to be.
>> >>>
>> >>> I think that if we need to generate some BOM for use by external
>> >>> projects, it should be done as a separate step and artifact which
>> >>> acquires versions from the parent.  I believe we had it this way at
>> >>> one point, didn't we?
>> >>>
>> >>> Anyway I think this change didn't work out, and we should undo it
>> >>> while it's still remotely possible.  WDYT?
>> >>>
>> >>> --
>> >>> - DML
>> >>> _______________________________________________
>> >>> wildfly-dev mailing list
>> >>> wildfly-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >
>> >
>> >
>> > --
>> > - DML
>> > _______________________________________________
>> > wildfly-dev mailing list
>> > wildfly-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>



-- 
- DML

From emartins at redhat.com  Tue May  8 11:12:07 2018
From: emartins at redhat.com (Eduardo Martins)
Date: Tue, 8 May 2018 16:12:07 +0100
Subject: [wildfly-dev] Proposal to revert component-matrix change
In-Reply-To: <CACa2xU8VE4xez2Ui5zVgtOV2UrPt35bvGpAbhPRTGi9RH_+xpQ@mail.gmail.com>
References: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
	<CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>
	<CANghgrQ5Tv9iprCBtbcP-XjF7S9pFSp1WztRHYYg7h1MYpyNhw@mail.gmail.com>
	<E44D4A57-C2A1-4B45-98AA-D90C56F82B24@redhat.com>
	<CACa2xU8VE4xez2Ui5zVgtOV2UrPt35bvGpAbhPRTGi9RH_+xpQ@mail.gmail.com>
Message-ID: <2D720673-FE26-4A9C-A863-CF2614DC0833@redhat.com>

We also revert back to what we had before in QS, and work out a better solution from there.

?E

> On 08 May 2018, at 16:06, Rostislav Svoboda <rsvoboda at redhat.com> wrote:
> 
> Tomaz mentioned Quickstarts as one of the reasons to have BOMs in WF and WF-CORE.
> 
> Eduardo should confirm that revert is fine for QS.
> 
> Rostislav
> 
> On Sat, May 5, 2018 at 11:25 AM, Kabir Khan <kkhan at redhat.com <mailto:kkhan at redhat.com>> wrote:
> Perhaps https://github.com/jboss/bom-builder-maven-plugin <https://github.com/jboss/bom-builder-maven-plugin> can be used? I've not played with it
> 
> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>> wrote:
> > 
> > I've created https://issues.jboss.org/browse/WFLY-10330 <https://issues.jboss.org/browse/WFLY-10330> and
> > https://issues.jboss.org/browse/WFCORE-3803 <https://issues.jboss.org/browse/WFCORE-3803> to track this.
> > 
> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
> >> I agree. We can break the bom cycle a different way.
> >> 
> >>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>> wrote:
> >>> 
> >>> I propose we revert the component-matrix change.  This change is
> >>> ostensibly to help in the creation of a BOM for the client libraries
> >>> and other dependent projects; however, the cost has turned out to be
> >>> somewhat higher than expected.
> >>> 
> >>> IntelliJ seems to be unable to cope with dependency changes in the
> >>> project due to the use of import from the root POM.  This means that
> >>> the entire project must be force-reimported from time to time to keep
> >>> dependencies up to date, and forgetting to do so can lead to
> >>> development issues and lost time.
> >>> 
> >>> Also, I've observed that Maven itself does not always correctly
> >>> resolve versions anymore, when you're building from a submodule.  I
> >>> don't really know why this is the case but I suspect that it's due to
> >>> some algorithmic ambiguity when the dependency tree is not linear like
> >>> it used to be.
> >>> 
> >>> I think that if we need to generate some BOM for use by external
> >>> projects, it should be done as a separate step and artifact which
> >>> acquires versions from the parent.  I believe we had it this way at
> >>> one point, didn't we?
> >>> 
> >>> Anyway I think this change didn't work out, and we should undo it
> >>> while it's still remotely possible.  WDYT?
> >>> 
> >>> --
> >>> - 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>
> > 
> > 
> > 
> > -- 
> > - 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>
> 
> 
> _______________________________________________
> 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>
> 

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

From brian.stansberry at redhat.com  Tue May  8 11:45:17 2018
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 8 May 2018 10:45:17 -0500
Subject: [wildfly-dev] Proposal to revert component-matrix change
In-Reply-To: <E44D4A57-C2A1-4B45-98AA-D90C56F82B24@redhat.com>
References: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
	<CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>
	<CANghgrQ5Tv9iprCBtbcP-XjF7S9pFSp1WztRHYYg7h1MYpyNhw@mail.gmail.com>
	<E44D4A57-C2A1-4B45-98AA-D90C56F82B24@redhat.com>
Message-ID: <CAPhbRDYpJVgmwHC08PHtrGH+tUzzigu6zX6Ht-OXZqfymSNFVA@mail.gmail.com>

Hi Paul and Petr,

Do you know of any uses of this plugin we could learn from?

Best regards,
Brian

On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan at redhat.com> wrote:

> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be used?
> I've not played with it
>
> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd at redhat.com> wrote:
> >
> > I've created https://issues.jboss.org/browse/WFLY-10330 and
> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
> >
> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene at redhat.com>
> wrote:
> >> I agree. We can break the bom cycle a different way.
> >>
> >>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd at redhat.com>
> wrote:
> >>>
> >>> I propose we revert the component-matrix change.  This change is
> >>> ostensibly to help in the creation of a BOM for the client libraries
> >>> and other dependent projects; however, the cost has turned out to be
> >>> somewhat higher than expected.
> >>>
> >>> IntelliJ seems to be unable to cope with dependency changes in the
> >>> project due to the use of import from the root POM.  This means that
> >>> the entire project must be force-reimported from time to time to keep
> >>> dependencies up to date, and forgetting to do so can lead to
> >>> development issues and lost time.
> >>>
> >>> Also, I've observed that Maven itself does not always correctly
> >>> resolve versions anymore, when you're building from a submodule.  I
> >>> don't really know why this is the case but I suspect that it's due to
> >>> some algorithmic ambiguity when the dependency tree is not linear like
> >>> it used to be.
> >>>
> >>> I think that if we need to generate some BOM for use by external
> >>> projects, it should be done as a separate step and artifact which
> >>> acquires versions from the parent.  I believe we had it this way at
> >>> one point, didn't we?
> >>>
> >>> Anyway I think this change didn't work out, and we should undo it
> >>> while it's still remotely possible.  WDYT?
> >>>
> >>> --
> >>> - DML
> >>> _______________________________________________
> >>> wildfly-dev mailing list
> >>> wildfly-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
> >
> > --
> > - DML
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



-- 
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/20180508/8753ce93/attachment-0001.html 

From brian.stansberry at redhat.com  Tue May  8 13:45:37 2018
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 8 May 2018 12:45:37 -0500
Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan
 Openshift Template
In-Reply-To: <CALaezvUUXYwrhPRNXF-CVQgv7EEYVFW3YrTs=5wabBN9rtsyBg@mail.gmail.com>
References: <CAFm4XO1sd48hcd76PF6THjXpExzKoHC=GgU7BwEUnwRV8o=avw@mail.gmail.com>
	<CAA9R9O77sdZA3b=AXudPmBUrfZXYJXU+3+KGzeV7H=BJ=7PcNQ@mail.gmail.com>
	<CAFm4XO1Ld81pjqfvw7G+EXit+uYkkJKtzpi=fYvkh1Sr-hhofw@mail.gmail.com>
	<CAA9R9O6ZfZ3HzpOQs0dnNvrvGB0tPR_T9qZSvCh1aaKP3qjotw@mail.gmail.com>
	<CAFMDs3DFJZd5LkhVwhzdyTQ15VskgcRgCLiAgAc5rkCDwdpVhQ@mail.gmail.com>
	<CAA9R9O77t21M=D8bMoQp7HsvHMsTQO2J_+k_iKgKQucNLZWeMA@mail.gmail.com>
	<CALaezvUOXKEE87iTagAnE-Dnx2SYGefmGOTbVkih0R_X-HuUQQ@mail.gmail.com>
	<CAA9R9O6HJk+CAC7X4QG07zO3Wtq8=rVq9we5UCKUmywjVENZ2A@mail.gmail.com>
	<CALaezvVJLuv4OYqdKk73gNLPiUyE2h-FQtU5dF8xfc-7XFPaFg@mail.gmail.com>
	<CAA9R9O7rYHmN6zSk+oP43Je3a4DQBjZw_+Ox9RmG5HbH5WnBag@mail.gmail.com>
	<CALaezvVTZxFDo+auOALk3tjXC1nkTShZuZu5364GQFSNrcPFtg@mail.gmail.com>
	<CAA9R9O4rb+VqbgTWppg0TK+_J9W=3xVrs+ac1gnO1MoCTXFoEw@mail.gmail.com>
	<CAPhbRDaTN4T3KvPud8Rk45m-b_C=1KhasahO4_uJqqBz1f_=Vw@mail.gmail.com>
	<CALaezvUUXYwrhPRNXF-CVQgv7EEYVFW3YrTs=5wabBN9rtsyBg@mail.gmail.com>
Message-ID: <CAPhbRDbEbZ3ggVNKYN32f-KnmAA3vC9_q3BXeJuKEXpaSfjDuA@mail.gmail.com>

I might have missed something along the way, but if they are going to do
scripting wouldn't they just set the attribute to ${jboss.node.name} and
count on the fact that this is unique per pod?

On Tue, May 8, 2018 at 3:28 AM, Tom Jenkinson <tom.jenkinson at redhat.com>
wrote:

> Thanks for confirming Brian.
>
> Perhaps we could set it to:
> node-identifier="${jboss.tx.node.id:1}"
> (a bit like https://github.com/jboss-developer/jboss-eap-
> quickstarts/tree/7.1/jts)
>
> Sebastian could set -Djboss.tx.node.id during startup in a script?
>
>
>
> On 7 May 2018 at 22:08, Brian Stansberry <brian.stansberry at redhat.com>
> wrote:
>
>> If it's not already set, WildFly sets the system property jboss.node.name
>> at the very beginning of server boot, so ${jboss.node.name*:1*} would
>> not resolve to 1.
>>
>> On Sun, May 6, 2018 at 6:10 PM, Sebastian Laskawiec <slaskawi at redhat.com>
>> wrote:
>>
>>> Ok, so how about doing the same thing you suggested, but just more
>>> explicitly - adding node-identifier="${jboss.node.name*:1*}". This way
>>> the bare metal deployment should be happy (since the default is still 1)
>>> and we wouldn't need to override it in Infinispan.
>>>
>>> On Tue, May 1, 2018 at 10:09 AM Tom Jenkinson <tom.jenkinson at redhat.com>
>>> wrote:
>>>
>>>> I am not sure - the default should be "1" for the bare metal case so
>>>> the warning is reliably triggered but the default can be the pod name for
>>>> OpenShift templates that only allow a single instance of the application
>>>> server - does that help?
>>>>
>>>> The file you looked to want to edit is shared by bare metal and other
>>>> deployment environments so it would be confusing to set the default to
>>>> jboss.node.name there IMO.
>>>>
>>>> On 1 May 2018 at 03:39, Sebastian Laskawiec <slaskawi at redhat.com>
>>>> wrote:
>>>>
>>>>> Fair enough Tom. Thanks for explanation.
>>>>>
>>>>> One more request - would you guys be OK with me adding
>>>>> a node-identifier="${jboss.node.name}" to the transaction subsystem
>>>>> template [1]? This way we wouldn't need to copy it into Infinispan (since
>>>>> we need to set it).
>>>>>
>>>>> [1] https://github.com/wildfly/wildfly/blob/master/transacti
>>>>> ons/src/main/resources/subsystem-templates/transactions.xml#L6
>>>>>
>>>>> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson <
>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>
>>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec <slaskawi at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hey Tom,
>>>>>>>
>>>>>>> Comments inlined.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Sebastian
>>>>>>>
>>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson <
>>>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 16 April 2018 at 09:31, <> wrote:
>>>>>>>>
>>>>>>>>> Adding +WildFly Dev <wildfly-dev at lists.jboss.org> to the loop
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks for the explanation Rado.
>>>>>>>>>
>>>>>>>>> TL;DR: A while ago Sanne pointed out that we do not set
>>>>>>>>> `node-identifier`
>>>>>>>>> in transaction subsystem by default. The default value for the
>>>>>>>>> `node-identifier` attribute it `1`. Not setting this attribute
>>>>>>>>> might cause
>>>>>>>>> problems in transaction recovery. Perhaps we could follow Rado's
>>>>>>>>> idea and
>>>>>>>>> set it to node name by default?
>>>>>>>>>
>>>>>>>> Indeed - it would cause serious data integrity problems if a
>>>>>>>> non-unique node-identifier is used.
>>>>>>>>
>>>>>>>>> Some more comments inlined.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Sebastian
>>>>>>>>>
>>>>>>>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar <rhusar at
>>>>>>>>> redhat.com> wrote:
>>>>>>>>>
>>>>>>>>> > Hi Sebastian,
>>>>>>>>> >
>>>>>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec
>>>>>>>>> > <slaskawi at redhat.com> wrote:
>>>>>>>>> > > Hey Rado, Paul,
>>>>>>>>> > >
>>>>>>>>> > > I started looking into this issue and it turned out that WF
>>>>>>>>> subsystem
>>>>>>>>> > > template doesn't provide `node-identifier` attribute [1].
>>>>>>>>> >
>>>>>>>>> > I assume you mean that the default WildFly server profiles do not
>>>>>>>>>
>>>>>>>> > explicitly define the attribute. Right ? thus the value defaults
>>>>>>>>> in
>>>>>>>>
>>>>>>>>
>>>>>>>>> > the model to "1"
>>>>>>>>> >
>>>>>>>>> > https://github.com/wildfly/wildfly/blob/master/transactions/
>>>>>>>>> src/main/java/org/jboss/as/txn/subsystem/TransactionSubsyste
>>>>>>>>> mRootResourceDefinition.java#L97
>>>>>>>>> > which sole intention seems to be to log a warning on boot if the
>>>>>>>>> value
>>>>>>>>> > is unchanged.
>>>>>>>>> > Why they decided on a constant that will be inherently not
>>>>>>>>> unique as
>>>>>>>>> > opposed to defaulting to the node name (which we already require
>>>>>>>>> to be
>>>>>>>>> > unique) as clustering node name or undertow instance-id does, is
>>>>>>>>> > unclear to me.
>>>>>>>>> > Some context is on https://issues.jboss.org/browse/WFLY-1119.
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> In OpenShift environment we could set it to `hostname`. This is
>>>>>>>>> guaranteed
>>>>>>>>> to be unique in whole OpenShift cluster.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We do this too in EAP images.
>>>>>>>> To Rado's point, the default is "1" so we can print the warning to
>>>>>>>> alert people they are misconfigured - it seems to be working :)
>>>>>>>>
>>>>>>>
>>>>>>> This is the point. From my understanding, if we set it to node name
>>>>>>> (instead of "1"), we could make it always work correctly. We could even
>>>>>>> remove the code that emits the warning (since the node name needs to be
>>>>>>> unique).
>>>>>>>
>>>>>>> To sum it up - if we decided to proceed this way, there would be no
>>>>>>> requirement of setting the node-identifier at all.
>>>>>>>
>>>>>>
>>>>>> For OpenShift you are right there is no requirement for someone to
>>>>>> change the node-identifier from the podname and so that is why EAP images
>>>>>> do that.
>>>>>>
>>>>>> For bare-metal it is different as there can be two servers on the
>>>>>> same machine so they were configured to use the hostname as they
>>>>>> node-identifier then if they were also connected to the same resource
>>>>>> managers or the same object store they would interfere with each other.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>>> > > I'm not sure if you guys are the right people to ask, but is
>>>>>>>>> it safe to
>>>>>>>>> > > leave it set to default? Or shall I override our Infinispan
>>>>>>>>> templates and
>>>>>>>>> > > add this parameter (as I mentioned before, in OpenShift this I
>>>>>>>>> wanted to
>>>>>>>>> > set
>>>>>>>>> > > it as Pod name trimmed to the last 23 chars since this is the
>>>>>>>>> limit).
>>>>>>>>>
>>>>>>>> Putting a response to this in line - I am not certain who
>>>>>>>> originally proposed this.
>>>>>>>>
>>>>>>>> You must use a globally unique node-identifier. If you are certain
>>>>>>>> the last 23 characters guarantee that it would be valid - if there is a
>>>>>>>> chance they are not unique it is not valid to trim.
>>>>>>>>
>>>>>>>
>>>>>>> If that's not an issue, again, we could use the same limit as we
>>>>>>> have for node name.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>>> > It is not safe to leave it set to "1" as that results in
>>>>>>>>> inconsistent
>>>>>>>>> > processing of transaction recovery.
>>>>>>>>> > IIUC we already set it to the node name for both EAP and JDG
>>>>>>>>> >
>>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/master/os
>>>>>>>>> -eap70-openshift/added/standalone-openshift.xml#L411
>>>>>>>>> >
>>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/master/os
>>>>>>>>> -jdg7-conffiles/added/clustered-openshift.xml#L282
>>>>>>>>>
>>>>>>>> > which in turn defaults to the pod name ? so which profiles are we
>>>>>>>>
>>>>>>>>
>>>>>>>>> > talking about here?
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> Granted, we set it by default in CCT Modules. However in
>>>>>>>>> Infinispan we just
>>>>>>>>> grab provided transaction subsystem when rendering full
>>>>>>>>> configuration from
>>>>>>>>> featurepacks:
>>>>>>>>> https://github.com/infinispan/infinispan/blob/master/server/
>>>>>>>>> integration/feature-pack/src/main/resources/configuration/st
>>>>>>>>> andalone/subsystems-cloud.xml#L19
>>>>>>>>>
>>>>>>>>> The default configuration XML doesn't contain the `node-identifier`
>>>>>>>>> attribute. I can add it manually in the cloud.xml but I believe
>>>>>>>>> the right
>>>>>>>>> approach is to modify the transaction subsystem.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> > Rado
>>>>>>>>> >
>>>>>>>>> > > Thanks,
>>>>>>>>> > > Seb
>>>>>>>>> > >
>>>>>>>>> > > [1] usually set to node-identifier="${jboss.node.name}"
>>>>>>>>> > >
>>>>>>>>> > >
>>>>>>>>>
>>>>>>>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero <sanne at
>>>>>>>>> infinispan.org>
>>>>>>>>> > > wrote:
>>>>>>>>> > >>
>>>>>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec <slaskawi at
>>>>>>>>> redhat.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>> > wrote:
>>>>>>>>> > >> > Thanks for looking into it Sanne. Of course, we should add
>>>>>>>>> it (it can
>>>>>>>>> > be
>>>>>>>>> > >> > set
>>>>>>>>> > >> > to the same name as hostname since those are unique in
>>>>>>>>> Kubernetes).
>>>>>>>>> > >> >
>>>>>>>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 for it.
>>>>>>>>> > >> >
>>>>>>>>> > >> > Thanks again!
>>>>>>>>> > >> > Seb
>>>>>>>>> > >>
>>>>>>>>> > >> Thanks Sebastian!
>>>>>>>>> > >>
>>>>>>>>> > >> >
>>>>>>>>>
>>>>>>>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero <sanne at
>>>>>>>>> infinispan.org>
>>>>>>>>
>>>>>>>>
>>>>>>>>> > >> > wrote:
>>>>>>>>> > >> >>
>>>>>>>>> > >> >> Hi all,
>>>>>>>>> > >> >>
>>>>>>>>> > >> >> I've started to use the Infinispan Openshift Template and
>>>>>>>>> was
>>>>>>>>> > browsing
>>>>>>>>> > >> >> through the errors and warnings this produces.
>>>>>>>>> > >> >>
>>>>>>>>> > >> >> In particular I noticed "WFLYTX0013: Node identifier
>>>>>>>>> property is set
>>>>>>>>> > >> >> to the default value. Please make sure it is unique."
>>>>>>>>> being produced
>>>>>>>>> > >> >> by the transaction system.
>>>>>>>>> > >> >>
>>>>>>>>> > >> >> The node id is usually not needed for developer's
>>>>>>>>> convenience and
>>>>>>>>> > >> >> assuming there's a single node in "dev mode", yet clearly
>>>>>>>>> the
>>>>>>>>> > >> >> Infinispan template is meant to work with multiple nodes
>>>>>>>>> running so
>>>>>>>>> > >> >> this warning seems concerning.
>>>>>>>>> > >> >>
>>>>>>>>> > >> >> I'm not sure what the impact is on the transaction manager
>>>>>>>>> so I asked
>>>>>>>>> > >> >> on the Narayana forums; Tom pointed me to some thourough
>>>>>>>>> design
>>>>>>>>> > >> >> documents and also suggested the EAP image does set the
>>>>>>>>> node
>>>>>>>>> > >> >> identifier:
>>>>>>>>> > >> >>  - https://developer.jboss.org/message/981702#981702
>>>>>>>>> > >> >>
>>>>>>>>> > >> >> WDYT? we probably want the Infinispan template to set this
>>>>>>>>> as well,
>>>>>>>>> > or
>>>>>>>>> > >> >> silence the warning?
>>>>>>>>> > >> >>
>>>>>>>>> > >> >> Thanks,
>>>>>>>>> > >> >> Sanne
>>>>>>>>> > >> >> _______________________________________________
>>>>>>>>> > >> >> infinispan-dev mailing list
>>>>>>>>>
>>>>>>>> > >> >> infinispan-dev at lists.jboss.org
>>>>>>>>
>>>>>>>>
>>>>>>>>> > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>> > >> >
>>>>>>>>> > >> >
>>>>>>>>> > >> > _______________________________________________
>>>>>>>>> > >> > infinispan-dev mailing list
>>>>>>>>>
>>>>>>>> > >> > infinispan-dev at lists.jboss.org
>>>>>>>>
>>>>>>>>
>>>>>>>>> > >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>> > >> _______________________________________________
>>>>>>>>> > >> infinispan-dev mailing list
>>>>>>>>> > >> infinispan-dev at lists.jboss.org
>>>>>>>>> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>> >
>>>>>>>>> -------------- next part --------------
>>>>>>>>> An HTML attachment was scrubbed...
>>>>>>>>> URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/201
>>>>>>>>> 80416/65962cf1/attachment-0001.html
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>
>>> _______________________________________________
>>> 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/20180508/fff97469/attachment-0001.html 

From tom.jenkinson at redhat.com  Tue May  8 16:07:52 2018
From: tom.jenkinson at redhat.com (Tom Jenkinson)
Date: Tue, 8 May 2018 21:07:52 +0100
Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan
 Openshift Template
In-Reply-To: <CAPhbRDbEbZ3ggVNKYN32f-KnmAA3vC9_q3BXeJuKEXpaSfjDuA@mail.gmail.com>
References: <CAFm4XO1sd48hcd76PF6THjXpExzKoHC=GgU7BwEUnwRV8o=avw@mail.gmail.com>
	<CAA9R9O77sdZA3b=AXudPmBUrfZXYJXU+3+KGzeV7H=BJ=7PcNQ@mail.gmail.com>
	<CAFm4XO1Ld81pjqfvw7G+EXit+uYkkJKtzpi=fYvkh1Sr-hhofw@mail.gmail.com>
	<CAA9R9O6ZfZ3HzpOQs0dnNvrvGB0tPR_T9qZSvCh1aaKP3qjotw@mail.gmail.com>
	<CAFMDs3DFJZd5LkhVwhzdyTQ15VskgcRgCLiAgAc5rkCDwdpVhQ@mail.gmail.com>
	<CAA9R9O77t21M=D8bMoQp7HsvHMsTQO2J_+k_iKgKQucNLZWeMA@mail.gmail.com>
	<CALaezvUOXKEE87iTagAnE-Dnx2SYGefmGOTbVkih0R_X-HuUQQ@mail.gmail.com>
	<CAA9R9O6HJk+CAC7X4QG07zO3Wtq8=rVq9we5UCKUmywjVENZ2A@mail.gmail.com>
	<CALaezvVJLuv4OYqdKk73gNLPiUyE2h-FQtU5dF8xfc-7XFPaFg@mail.gmail.com>
	<CAA9R9O7rYHmN6zSk+oP43Je3a4DQBjZw_+Ox9RmG5HbH5WnBag@mail.gmail.com>
	<CALaezvVTZxFDo+auOALk3tjXC1nkTShZuZu5364GQFSNrcPFtg@mail.gmail.com>
	<CAA9R9O4rb+VqbgTWppg0TK+_J9W=3xVrs+ac1gnO1MoCTXFoEw@mail.gmail.com>
	<CAPhbRDaTN4T3KvPud8Rk45m-b_C=1KhasahO4_uJqqBz1f_=Vw@mail.gmail.com>
	<CALaezvUUXYwrhPRNXF-CVQgv7EEYVFW3YrTs=5wabBN9rtsyBg@mail.gmail.com>
	<CAPhbRDbEbZ3ggVNKYN32f-KnmAA3vC9_q3BXeJuKEXpaSfjDuA@mail.gmail.com>
Message-ID: <CALaezvWO_q0ghyRNmhr2e3D4RwRUo9pY+nbwBannEy+YYnR0nw@mail.gmail.com>

I think they want to avoid changing the standalone.xml file and just want
to control it from their startup script.

On 8 May 2018 at 18:45, Brian Stansberry <brian.stansberry at redhat.com>
wrote:

> I might have missed something along the way, but if they are going to do
> scripting wouldn't they just set the attribute to ${jboss.node.name} and
> count on the fact that this is unique per pod?
>
> On Tue, May 8, 2018 at 3:28 AM, Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
>
>> Thanks for confirming Brian.
>>
>> Perhaps we could set it to:
>> node-identifier="${jboss.tx.node.id:1}"
>> (a bit like https://github.com/jboss-developer/jboss-eap-quickstart
>> s/tree/7.1/jts)
>>
>> Sebastian could set -Djboss.tx.node.id during startup in a script?
>>
>>
>>
>> On 7 May 2018 at 22:08, Brian Stansberry <brian.stansberry at redhat.com>
>> wrote:
>>
>>> If it's not already set, WildFly sets the system property
>>> jboss.node.name at the very beginning of server boot, so ${
>>> jboss.node.name*:1*} would not resolve to 1.
>>>
>>> On Sun, May 6, 2018 at 6:10 PM, Sebastian Laskawiec <slaskawi at redhat.com
>>> > wrote:
>>>
>>>> Ok, so how about doing the same thing you suggested, but just more
>>>> explicitly - adding node-identifier="${jboss.node.name*:1*}". This way
>>>> the bare metal deployment should be happy (since the default is still 1)
>>>> and we wouldn't need to override it in Infinispan.
>>>>
>>>> On Tue, May 1, 2018 at 10:09 AM Tom Jenkinson <tom.jenkinson at redhat.com>
>>>> wrote:
>>>>
>>>>> I am not sure - the default should be "1" for the bare metal case so
>>>>> the warning is reliably triggered but the default can be the pod name for
>>>>> OpenShift templates that only allow a single instance of the application
>>>>> server - does that help?
>>>>>
>>>>> The file you looked to want to edit is shared by bare metal and other
>>>>> deployment environments so it would be confusing to set the default to
>>>>> jboss.node.name there IMO.
>>>>>
>>>>> On 1 May 2018 at 03:39, Sebastian Laskawiec <slaskawi at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> Fair enough Tom. Thanks for explanation.
>>>>>>
>>>>>> One more request - would you guys be OK with me adding
>>>>>> a node-identifier="${jboss.node.name}" to the transaction subsystem
>>>>>> template [1]? This way we wouldn't need to copy it into Infinispan (since
>>>>>> we need to set it).
>>>>>>
>>>>>> [1] https://github.com/wildfly/wildfly/blob/master/transacti
>>>>>> ons/src/main/resources/subsystem-templates/transactions.xml#L6
>>>>>>
>>>>>> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson <
>>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>>
>>>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec <slaskawi at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hey Tom,
>>>>>>>>
>>>>>>>> Comments inlined.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Sebastian
>>>>>>>>
>>>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson <
>>>>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 16 April 2018 at 09:31, <> wrote:
>>>>>>>>>
>>>>>>>>>> Adding +WildFly Dev <wildfly-dev at lists.jboss.org> to the loop
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks for the explanation Rado.
>>>>>>>>>>
>>>>>>>>>> TL;DR: A while ago Sanne pointed out that we do not set
>>>>>>>>>> `node-identifier`
>>>>>>>>>> in transaction subsystem by default. The default value for the
>>>>>>>>>> `node-identifier` attribute it `1`. Not setting this attribute
>>>>>>>>>> might cause
>>>>>>>>>> problems in transaction recovery. Perhaps we could follow Rado's
>>>>>>>>>> idea and
>>>>>>>>>> set it to node name by default?
>>>>>>>>>>
>>>>>>>>> Indeed - it would cause serious data integrity problems if a
>>>>>>>>> non-unique node-identifier is used.
>>>>>>>>>
>>>>>>>>>> Some more comments inlined.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Sebastian
>>>>>>>>>>
>>>>>>>>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar <rhusar at
>>>>>>>>>> redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>> > Hi Sebastian,
>>>>>>>>>> >
>>>>>>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec
>>>>>>>>>> > <slaskawi at redhat.com> wrote:
>>>>>>>>>> > > Hey Rado, Paul,
>>>>>>>>>> > >
>>>>>>>>>> > > I started looking into this issue and it turned out that WF
>>>>>>>>>> subsystem
>>>>>>>>>> > > template doesn't provide `node-identifier` attribute [1].
>>>>>>>>>> >
>>>>>>>>>> > I assume you mean that the default WildFly server profiles do
>>>>>>>>>> not
>>>>>>>>>>
>>>>>>>>> > explicitly define the attribute. Right ? thus the value defaults
>>>>>>>>>> in
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> > the model to "1"
>>>>>>>>>> >
>>>>>>>>>> > https://github.com/wildfly/wildfly/blob/master/transactions/
>>>>>>>>>> src/main/java/org/jboss/as/txn/subsystem/TransactionSubsyste
>>>>>>>>>> mRootResourceDefinition.java#L97
>>>>>>>>>> > which sole intention seems to be to log a warning on boot if
>>>>>>>>>> the value
>>>>>>>>>> > is unchanged.
>>>>>>>>>> > Why they decided on a constant that will be inherently not
>>>>>>>>>> unique as
>>>>>>>>>> > opposed to defaulting to the node name (which we already
>>>>>>>>>> require to be
>>>>>>>>>> > unique) as clustering node name or undertow instance-id does, is
>>>>>>>>>> > unclear to me.
>>>>>>>>>> > Some context is on https://issues.jboss.org/browse/WFLY-1119.
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>> In OpenShift environment we could set it to `hostname`. This is
>>>>>>>>>> guaranteed
>>>>>>>>>> to be unique in whole OpenShift cluster.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> We do this too in EAP images.
>>>>>>>>> To Rado's point, the default is "1" so we can print the warning to
>>>>>>>>> alert people they are misconfigured - it seems to be working :)
>>>>>>>>>
>>>>>>>>
>>>>>>>> This is the point. From my understanding, if we set it to node name
>>>>>>>> (instead of "1"), we could make it always work correctly. We could even
>>>>>>>> remove the code that emits the warning (since the node name needs to be
>>>>>>>> unique).
>>>>>>>>
>>>>>>>> To sum it up - if we decided to proceed this way, there would be no
>>>>>>>> requirement of setting the node-identifier at all.
>>>>>>>>
>>>>>>>
>>>>>>> For OpenShift you are right there is no requirement for someone to
>>>>>>> change the node-identifier from the podname and so that is why EAP images
>>>>>>> do that.
>>>>>>>
>>>>>>> For bare-metal it is different as there can be two servers on the
>>>>>>> same machine so they were configured to use the hostname as they
>>>>>>> node-identifier then if they were also connected to the same resource
>>>>>>> managers or the same object store they would interfere with each other.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> > > I'm not sure if you guys are the right people to ask, but is
>>>>>>>>>> it safe to
>>>>>>>>>> > > leave it set to default? Or shall I override our Infinispan
>>>>>>>>>> templates and
>>>>>>>>>> > > add this parameter (as I mentioned before, in OpenShift this
>>>>>>>>>> I wanted to
>>>>>>>>>> > set
>>>>>>>>>> > > it as Pod name trimmed to the last 23 chars since this is the
>>>>>>>>>> limit).
>>>>>>>>>>
>>>>>>>>> Putting a response to this in line - I am not certain who
>>>>>>>>> originally proposed this.
>>>>>>>>>
>>>>>>>>> You must use a globally unique node-identifier. If you are certain
>>>>>>>>> the last 23 characters guarantee that it would be valid - if there is a
>>>>>>>>> chance they are not unique it is not valid to trim.
>>>>>>>>>
>>>>>>>>
>>>>>>>> If that's not an issue, again, we could use the same limit as we
>>>>>>>> have for node name.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> > It is not safe to leave it set to "1" as that results in
>>>>>>>>>> inconsistent
>>>>>>>>>> > processing of transaction recovery.
>>>>>>>>>> > IIUC we already set it to the node name for both EAP and JDG
>>>>>>>>>> >
>>>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/master/os
>>>>>>>>>> -eap70-openshift/added/standalone-openshift.xml#L411
>>>>>>>>>> >
>>>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/master/os
>>>>>>>>>> -jdg7-conffiles/added/clustered-openshift.xml#L282
>>>>>>>>>>
>>>>>>>>> > which in turn defaults to the pod name ? so which profiles are we
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> > talking about here?
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>> Granted, we set it by default in CCT Modules. However in
>>>>>>>>>> Infinispan we just
>>>>>>>>>> grab provided transaction subsystem when rendering full
>>>>>>>>>> configuration from
>>>>>>>>>> featurepacks:
>>>>>>>>>> https://github.com/infinispan/infinispan/blob/master/server/
>>>>>>>>>> integration/feature-pack/src/main/resources/configuration/st
>>>>>>>>>> andalone/subsystems-cloud.xml#L19
>>>>>>>>>>
>>>>>>>>>> The default configuration XML doesn't contain the
>>>>>>>>>> `node-identifier`
>>>>>>>>>> attribute. I can add it manually in the cloud.xml but I believe
>>>>>>>>>> the right
>>>>>>>>>> approach is to modify the transaction subsystem.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> > Rado
>>>>>>>>>> >
>>>>>>>>>> > > Thanks,
>>>>>>>>>> > > Seb
>>>>>>>>>> > >
>>>>>>>>>> > > [1] usually set to node-identifier="${jboss.node.name}"
>>>>>>>>>> > >
>>>>>>>>>> > >
>>>>>>>>>>
>>>>>>>>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero <sanne at
>>>>>>>>>> infinispan.org>
>>>>>>>>>> > > wrote:
>>>>>>>>>> > >>
>>>>>>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec <slaskawi at
>>>>>>>>>> redhat.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> > wrote:
>>>>>>>>>> > >> > Thanks for looking into it Sanne. Of course, we should add
>>>>>>>>>> it (it can
>>>>>>>>>> > be
>>>>>>>>>> > >> > set
>>>>>>>>>> > >> > to the same name as hostname since those are unique in
>>>>>>>>>> Kubernetes).
>>>>>>>>>> > >> >
>>>>>>>>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 for it.
>>>>>>>>>> > >> >
>>>>>>>>>> > >> > Thanks again!
>>>>>>>>>> > >> > Seb
>>>>>>>>>> > >>
>>>>>>>>>> > >> Thanks Sebastian!
>>>>>>>>>> > >>
>>>>>>>>>> > >> >
>>>>>>>>>>
>>>>>>>>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero <sanne at
>>>>>>>>>> infinispan.org>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> > >> > wrote:
>>>>>>>>>> > >> >>
>>>>>>>>>> > >> >> Hi all,
>>>>>>>>>> > >> >>
>>>>>>>>>> > >> >> I've started to use the Infinispan Openshift Template and
>>>>>>>>>> was
>>>>>>>>>> > browsing
>>>>>>>>>> > >> >> through the errors and warnings this produces.
>>>>>>>>>> > >> >>
>>>>>>>>>> > >> >> In particular I noticed "WFLYTX0013: Node identifier
>>>>>>>>>> property is set
>>>>>>>>>> > >> >> to the default value. Please make sure it is unique."
>>>>>>>>>> being produced
>>>>>>>>>> > >> >> by the transaction system.
>>>>>>>>>> > >> >>
>>>>>>>>>> > >> >> The node id is usually not needed for developer's
>>>>>>>>>> convenience and
>>>>>>>>>> > >> >> assuming there's a single node in "dev mode", yet clearly
>>>>>>>>>> the
>>>>>>>>>> > >> >> Infinispan template is meant to work with multiple nodes
>>>>>>>>>> running so
>>>>>>>>>> > >> >> this warning seems concerning.
>>>>>>>>>> > >> >>
>>>>>>>>>> > >> >> I'm not sure what the impact is on the transaction
>>>>>>>>>> manager so I asked
>>>>>>>>>> > >> >> on the Narayana forums; Tom pointed me to some thourough
>>>>>>>>>> design
>>>>>>>>>> > >> >> documents and also suggested the EAP image does set the
>>>>>>>>>> node
>>>>>>>>>> > >> >> identifier:
>>>>>>>>>> > >> >>  - https://developer.jboss.org/message/981702#981702
>>>>>>>>>> > >> >>
>>>>>>>>>> > >> >> WDYT? we probably want the Infinispan template to set
>>>>>>>>>> this as well,
>>>>>>>>>> > or
>>>>>>>>>> > >> >> silence the warning?
>>>>>>>>>> > >> >>
>>>>>>>>>> > >> >> Thanks,
>>>>>>>>>> > >> >> Sanne
>>>>>>>>>> > >> >> _______________________________________________
>>>>>>>>>> > >> >> infinispan-dev mailing list
>>>>>>>>>>
>>>>>>>>> > >> >> infinispan-dev at lists.jboss.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>>> > >> >
>>>>>>>>>> > >> >
>>>>>>>>>> > >> > _______________________________________________
>>>>>>>>>> > >> > infinispan-dev mailing list
>>>>>>>>>>
>>>>>>>>> > >> > infinispan-dev at lists.jboss.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> > >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>>> > >> _______________________________________________
>>>>>>>>>> > >> infinispan-dev mailing list
>>>>>>>>>> > >> infinispan-dev at lists.jboss.org
>>>>>>>>>> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>>> >
>>>>>>>>>> -------------- next part --------------
>>>>>>>>>> An HTML attachment was scrubbed...
>>>>>>>>>> URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/201
>>>>>>>>>> 80416/65962cf1/attachment-0001.html
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>
>>>> _______________________________________________
>>>> 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/20180508/2d1df256/attachment-0001.html 

From brian.stansberry at redhat.com  Tue May  8 18:05:31 2018
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 8 May 2018 17:05:31 -0500
Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan
 Openshift Template
In-Reply-To: <CALaezvWO_q0ghyRNmhr2e3D4RwRUo9pY+nbwBannEy+YYnR0nw@mail.gmail.com>
References: <CAFm4XO1sd48hcd76PF6THjXpExzKoHC=GgU7BwEUnwRV8o=avw@mail.gmail.com>
	<CAA9R9O77sdZA3b=AXudPmBUrfZXYJXU+3+KGzeV7H=BJ=7PcNQ@mail.gmail.com>
	<CAFm4XO1Ld81pjqfvw7G+EXit+uYkkJKtzpi=fYvkh1Sr-hhofw@mail.gmail.com>
	<CAA9R9O6ZfZ3HzpOQs0dnNvrvGB0tPR_T9qZSvCh1aaKP3qjotw@mail.gmail.com>
	<CAFMDs3DFJZd5LkhVwhzdyTQ15VskgcRgCLiAgAc5rkCDwdpVhQ@mail.gmail.com>
	<CAA9R9O77t21M=D8bMoQp7HsvHMsTQO2J_+k_iKgKQucNLZWeMA@mail.gmail.com>
	<CALaezvUOXKEE87iTagAnE-Dnx2SYGefmGOTbVkih0R_X-HuUQQ@mail.gmail.com>
	<CAA9R9O6HJk+CAC7X4QG07zO3Wtq8=rVq9we5UCKUmywjVENZ2A@mail.gmail.com>
	<CALaezvVJLuv4OYqdKk73gNLPiUyE2h-FQtU5dF8xfc-7XFPaFg@mail.gmail.com>
	<CAA9R9O7rYHmN6zSk+oP43Je3a4DQBjZw_+Ox9RmG5HbH5WnBag@mail.gmail.com>
	<CALaezvVTZxFDo+auOALk3tjXC1nkTShZuZu5364GQFSNrcPFtg@mail.gmail.com>
	<CAA9R9O4rb+VqbgTWppg0TK+_J9W=3xVrs+ac1gnO1MoCTXFoEw@mail.gmail.com>
	<CAPhbRDaTN4T3KvPud8Rk45m-b_C=1KhasahO4_uJqqBz1f_=Vw@mail.gmail.com>
	<CALaezvUUXYwrhPRNXF-CVQgv7EEYVFW3YrTs=5wabBN9rtsyBg@mail.gmail.com>
	<CAPhbRDbEbZ3ggVNKYN32f-KnmAA3vC9_q3BXeJuKEXpaSfjDuA@mail.gmail.com>
	<CALaezvWO_q0ghyRNmhr2e3D4RwRUo9pY+nbwBannEy+YYnR0nw@mail.gmail.com>
Message-ID: <CAPhbRDZVzXdsc8SGOFGbBQiW8Kwz5BeFDv-Wirm-Q_R-dxqO7Q@mail.gmail.com>

Ah, ok. I was thinking of scripting in the broad sense the various stuff
that goes into creating images.

In any case, I don't see any downside to having node-identifier="${jboss.tx.
node.id:1}" in the standard WF config files.



On Tue, May 8, 2018 at 3:07 PM, Tom Jenkinson <tom.jenkinson at redhat.com>
wrote:

> I think they want to avoid changing the standalone.xml file and just want
> to control it from their startup script.
>
> On 8 May 2018 at 18:45, Brian Stansberry <brian.stansberry at redhat.com>
> wrote:
>
>> I might have missed something along the way, but if they are going to do
>> scripting wouldn't they just set the attribute to ${jboss.node.name} and
>> count on the fact that this is unique per pod?
>>
>> On Tue, May 8, 2018 at 3:28 AM, Tom Jenkinson <tom.jenkinson at redhat.com>
>> wrote:
>>
>>> Thanks for confirming Brian.
>>>
>>> Perhaps we could set it to:
>>> node-identifier="${jboss.tx.node.id:1}"
>>> (a bit like https://github.com/jboss-developer/jboss-eap-quickstart
>>> s/tree/7.1/jts)
>>>
>>> Sebastian could set -Djboss.tx.node.id during startup in a script?
>>>
>>>
>>>
>>> On 7 May 2018 at 22:08, Brian Stansberry <brian.stansberry at redhat.com>
>>> wrote:
>>>
>>>> If it's not already set, WildFly sets the system property
>>>> jboss.node.name at the very beginning of server boot, so ${
>>>> jboss.node.name*:1*} would not resolve to 1.
>>>>
>>>> On Sun, May 6, 2018 at 6:10 PM, Sebastian Laskawiec <
>>>> slaskawi at redhat.com> wrote:
>>>>
>>>>> Ok, so how about doing the same thing you suggested, but just more
>>>>> explicitly - adding node-identifier="${jboss.node.name*:1*}". This
>>>>> way the bare metal deployment should be happy (since the default is still
>>>>> 1) and we wouldn't need to override it in Infinispan.
>>>>>
>>>>> On Tue, May 1, 2018 at 10:09 AM Tom Jenkinson <
>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>
>>>>>> I am not sure - the default should be "1" for the bare metal case so
>>>>>> the warning is reliably triggered but the default can be the pod name for
>>>>>> OpenShift templates that only allow a single instance of the application
>>>>>> server - does that help?
>>>>>>
>>>>>> The file you looked to want to edit is shared by bare metal and other
>>>>>> deployment environments so it would be confusing to set the default to
>>>>>> jboss.node.name there IMO.
>>>>>>
>>>>>> On 1 May 2018 at 03:39, Sebastian Laskawiec <slaskawi at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Fair enough Tom. Thanks for explanation.
>>>>>>>
>>>>>>> One more request - would you guys be OK with me adding
>>>>>>> a node-identifier="${jboss.node.name}" to the transaction subsystem
>>>>>>> template [1]? This way we wouldn't need to copy it into Infinispan (since
>>>>>>> we need to set it).
>>>>>>>
>>>>>>> [1] https://github.com/wildfly/wildfly/blob/master/transacti
>>>>>>> ons/src/main/resources/subsystem-templates/transactions.xml#L6
>>>>>>>
>>>>>>> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson <
>>>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>>>
>>>>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec <slaskawi at redhat.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Hey Tom,
>>>>>>>>>
>>>>>>>>> Comments inlined.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Sebastian
>>>>>>>>>
>>>>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson <
>>>>>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 16 April 2018 at 09:31, <> wrote:
>>>>>>>>>>
>>>>>>>>>>> Adding +WildFly Dev <wildfly-dev at lists.jboss.org> to the loop
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the explanation Rado.
>>>>>>>>>>>
>>>>>>>>>>> TL;DR: A while ago Sanne pointed out that we do not set
>>>>>>>>>>> `node-identifier`
>>>>>>>>>>> in transaction subsystem by default. The default value for the
>>>>>>>>>>> `node-identifier` attribute it `1`. Not setting this attribute
>>>>>>>>>>> might cause
>>>>>>>>>>> problems in transaction recovery. Perhaps we could follow Rado's
>>>>>>>>>>> idea and
>>>>>>>>>>> set it to node name by default?
>>>>>>>>>>>
>>>>>>>>>> Indeed - it would cause serious data integrity problems if a
>>>>>>>>>> non-unique node-identifier is used.
>>>>>>>>>>
>>>>>>>>>>> Some more comments inlined.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Sebastian
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar <rhusar at
>>>>>>>>>>> redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> > Hi Sebastian,
>>>>>>>>>>> >
>>>>>>>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec
>>>>>>>>>>> > <slaskawi at redhat.com> wrote:
>>>>>>>>>>> > > Hey Rado, Paul,
>>>>>>>>>>> > >
>>>>>>>>>>> > > I started looking into this issue and it turned out that WF
>>>>>>>>>>> subsystem
>>>>>>>>>>> > > template doesn't provide `node-identifier` attribute [1].
>>>>>>>>>>> >
>>>>>>>>>>> > I assume you mean that the default WildFly server profiles do
>>>>>>>>>>> not
>>>>>>>>>>>
>>>>>>>>>> > explicitly define the attribute. Right ? thus the value
>>>>>>>>>>> defaults in
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> > the model to "1"
>>>>>>>>>>> >
>>>>>>>>>>> > https://github.com/wildfly/wildfly/blob/master/transactions/
>>>>>>>>>>> src/main/java/org/jboss/as/txn/subsystem/TransactionSubsyste
>>>>>>>>>>> mRootResourceDefinition.java#L97
>>>>>>>>>>> > which sole intention seems to be to log a warning on boot if
>>>>>>>>>>> the value
>>>>>>>>>>> > is unchanged.
>>>>>>>>>>> > Why they decided on a constant that will be inherently not
>>>>>>>>>>> unique as
>>>>>>>>>>> > opposed to defaulting to the node name (which we already
>>>>>>>>>>> require to be
>>>>>>>>>>> > unique) as clustering node name or undertow instance-id does,
>>>>>>>>>>> is
>>>>>>>>>>> > unclear to me.
>>>>>>>>>>> > Some context is on https://issues.jboss.org/browse/WFLY-1119.
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>> In OpenShift environment we could set it to `hostname`. This is
>>>>>>>>>>> guaranteed
>>>>>>>>>>> to be unique in whole OpenShift cluster.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> We do this too in EAP images.
>>>>>>>>>> To Rado's point, the default is "1" so we can print the warning
>>>>>>>>>> to alert people they are misconfigured - it seems to be working :)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is the point. From my understanding, if we set it to node
>>>>>>>>> name (instead of "1"), we could make it always work correctly. We could
>>>>>>>>> even remove the code that emits the warning (since the node name needs to
>>>>>>>>> be unique).
>>>>>>>>>
>>>>>>>>> To sum it up - if we decided to proceed this way, there would be
>>>>>>>>> no requirement of setting the node-identifier at all.
>>>>>>>>>
>>>>>>>>
>>>>>>>> For OpenShift you are right there is no requirement for someone to
>>>>>>>> change the node-identifier from the podname and so that is why EAP images
>>>>>>>> do that.
>>>>>>>>
>>>>>>>> For bare-metal it is different as there can be two servers on the
>>>>>>>> same machine so they were configured to use the hostname as they
>>>>>>>> node-identifier then if they were also connected to the same resource
>>>>>>>> managers or the same object store they would interfere with each other.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> > > I'm not sure if you guys are the right people to ask, but is
>>>>>>>>>>> it safe to
>>>>>>>>>>> > > leave it set to default? Or shall I override our Infinispan
>>>>>>>>>>> templates and
>>>>>>>>>>> > > add this parameter (as I mentioned before, in OpenShift this
>>>>>>>>>>> I wanted to
>>>>>>>>>>> > set
>>>>>>>>>>> > > it as Pod name trimmed to the last 23 chars since this is
>>>>>>>>>>> the limit).
>>>>>>>>>>>
>>>>>>>>>> Putting a response to this in line - I am not certain who
>>>>>>>>>> originally proposed this.
>>>>>>>>>>
>>>>>>>>>> You must use a globally unique node-identifier. If you are
>>>>>>>>>> certain the last 23 characters guarantee that it would be valid - if there
>>>>>>>>>> is a chance they are not unique it is not valid to trim.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If that's not an issue, again, we could use the same limit as we
>>>>>>>>> have for node name.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> > It is not safe to leave it set to "1" as that results in
>>>>>>>>>>> inconsistent
>>>>>>>>>>> > processing of transaction recovery.
>>>>>>>>>>> > IIUC we already set it to the node name for both EAP and JDG
>>>>>>>>>>> >
>>>>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/master/os
>>>>>>>>>>> -eap70-openshift/added/standalone-openshift.xml#L411
>>>>>>>>>>> >
>>>>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/master/os
>>>>>>>>>>> -jdg7-conffiles/added/clustered-openshift.xml#L282
>>>>>>>>>>>
>>>>>>>>>> > which in turn defaults to the pod name ? so which profiles are
>>>>>>>>>>> we
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> > talking about here?
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>> Granted, we set it by default in CCT Modules. However in
>>>>>>>>>>> Infinispan we just
>>>>>>>>>>> grab provided transaction subsystem when rendering full
>>>>>>>>>>> configuration from
>>>>>>>>>>> featurepacks:
>>>>>>>>>>> https://github.com/infinispan/infinispan/blob/master/server/
>>>>>>>>>>> integration/feature-pack/src/main/resources/configuration/st
>>>>>>>>>>> andalone/subsystems-cloud.xml#L19
>>>>>>>>>>>
>>>>>>>>>>> The default configuration XML doesn't contain the
>>>>>>>>>>> `node-identifier`
>>>>>>>>>>> attribute. I can add it manually in the cloud.xml but I believe
>>>>>>>>>>> the right
>>>>>>>>>>> approach is to modify the transaction subsystem.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> > Rado
>>>>>>>>>>> >
>>>>>>>>>>> > > Thanks,
>>>>>>>>>>> > > Seb
>>>>>>>>>>> > >
>>>>>>>>>>> > > [1] usually set to node-identifier="${jboss.node.name}"
>>>>>>>>>>> > >
>>>>>>>>>>> > >
>>>>>>>>>>>
>>>>>>>>>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero <sanne at
>>>>>>>>>>> infinispan.org>
>>>>>>>>>>> > > wrote:
>>>>>>>>>>> > >>
>>>>>>>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec <slaskawi at
>>>>>>>>>>> redhat.com>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> > wrote:
>>>>>>>>>>> > >> > Thanks for looking into it Sanne. Of course, we should
>>>>>>>>>>> add it (it can
>>>>>>>>>>> > be
>>>>>>>>>>> > >> > set
>>>>>>>>>>> > >> > to the same name as hostname since those are unique in
>>>>>>>>>>> Kubernetes).
>>>>>>>>>>> > >> >
>>>>>>>>>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 for it.
>>>>>>>>>>> > >> >
>>>>>>>>>>> > >> > Thanks again!
>>>>>>>>>>> > >> > Seb
>>>>>>>>>>> > >>
>>>>>>>>>>> > >> Thanks Sebastian!
>>>>>>>>>>> > >>
>>>>>>>>>>> > >> >
>>>>>>>>>>>
>>>>>>>>>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero <sanne at
>>>>>>>>>>> infinispan.org>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> > >> > wrote:
>>>>>>>>>>> > >> >>
>>>>>>>>>>> > >> >> Hi all,
>>>>>>>>>>> > >> >>
>>>>>>>>>>> > >> >> I've started to use the Infinispan Openshift Template
>>>>>>>>>>> and was
>>>>>>>>>>> > browsing
>>>>>>>>>>> > >> >> through the errors and warnings this produces.
>>>>>>>>>>> > >> >>
>>>>>>>>>>> > >> >> In particular I noticed "WFLYTX0013: Node identifier
>>>>>>>>>>> property is set
>>>>>>>>>>> > >> >> to the default value. Please make sure it is unique."
>>>>>>>>>>> being produced
>>>>>>>>>>> > >> >> by the transaction system.
>>>>>>>>>>> > >> >>
>>>>>>>>>>> > >> >> The node id is usually not needed for developer's
>>>>>>>>>>> convenience and
>>>>>>>>>>> > >> >> assuming there's a single node in "dev mode", yet
>>>>>>>>>>> clearly the
>>>>>>>>>>> > >> >> Infinispan template is meant to work with multiple nodes
>>>>>>>>>>> running so
>>>>>>>>>>> > >> >> this warning seems concerning.
>>>>>>>>>>> > >> >>
>>>>>>>>>>> > >> >> I'm not sure what the impact is on the transaction
>>>>>>>>>>> manager so I asked
>>>>>>>>>>> > >> >> on the Narayana forums; Tom pointed me to some thourough
>>>>>>>>>>> design
>>>>>>>>>>> > >> >> documents and also suggested the EAP image does set the
>>>>>>>>>>> node
>>>>>>>>>>> > >> >> identifier:
>>>>>>>>>>> > >> >>  - https://developer.jboss.org/message/981702#981702
>>>>>>>>>>> > >> >>
>>>>>>>>>>> > >> >> WDYT? we probably want the Infinispan template to set
>>>>>>>>>>> this as well,
>>>>>>>>>>> > or
>>>>>>>>>>> > >> >> silence the warning?
>>>>>>>>>>> > >> >>
>>>>>>>>>>> > >> >> Thanks,
>>>>>>>>>>> > >> >> Sanne
>>>>>>>>>>> > >> >> _______________________________________________
>>>>>>>>>>> > >> >> infinispan-dev mailing list
>>>>>>>>>>>
>>>>>>>>>> > >> >> infinispan-dev at lists.jboss.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>>>> > >> >
>>>>>>>>>>> > >> >
>>>>>>>>>>> > >> > _______________________________________________
>>>>>>>>>>> > >> > infinispan-dev mailing list
>>>>>>>>>>>
>>>>>>>>>> > >> > infinispan-dev at lists.jboss.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> > >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>>>> > >> _______________________________________________
>>>>>>>>>>> > >> infinispan-dev mailing list
>>>>>>>>>>> > >> infinispan-dev at lists.jboss.org
>>>>>>>>>>> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>>>> >
>>>>>>>>>>> -------------- next part --------------
>>>>>>>>>>> An HTML attachment was scrubbed...
>>>>>>>>>>> URL: http://lists.jboss.org/piperma
>>>>>>>>>>> il/wildfly-dev/attachments/20180416/65962cf1/attachment-0001
>>>>>>>>>>> .html
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> 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/20180508/75fa694e/attachment-0001.html 

From psakar at redhat.com  Wed May  9 02:30:46 2018
From: psakar at redhat.com (Petr Sakar)
Date: Wed, 9 May 2018 08:30:46 +0200
Subject: [wildfly-dev] Proposal to revert component-matrix change
In-Reply-To: <CAPhbRDYpJVgmwHC08PHtrGH+tUzzigu6zX6Ht-OXZqfymSNFVA@mail.gmail.com>
References: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
	<CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>
	<CANghgrQ5Tv9iprCBtbcP-XjF7S9pFSp1WztRHYYg7h1MYpyNhw@mail.gmail.com>
	<E44D4A57-C2A1-4B45-98AA-D90C56F82B24@redhat.com>
	<CAPhbRDYpJVgmwHC08PHtrGH+tUzzigu6zX6Ht-OXZqfymSNFVA@mail.gmail.com>
Message-ID: <a06540a6-d2be-054b-020b-8d65adce3a8f@redhat.com>

Plugin is used by EAP maven repo build to generate eap-runtime bom eg [1] based on the feature packs dependency tree.

Relevant configuration is [2] 
<http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-repository-testsuite.git/tree/repository-content/dependency-lists/eap-runtime-artifacts/pom.xml?h=eap-7.2.0.CD12#n105> 



Petr

[1] 
http://download-ipv4.eng.brq.redhat.com/brewroot/repos/jb-eap-7.2-maven-build/latest/maven/org/jboss/bom/eap-runtime-artifacts/7.2.0.CD12.CR2/eap-runtime-artifacts-7.2.0.CD12.CR2.pom

[2] 
http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-repository-testsuite.git/tree/repository-content/dependency-lists/eap-runtime-artifacts/pom.xml?h=eap-7.2.0.CD12#n105

On 05/08/2018 05:45 PM, Brian Stansberry wrote:
> Hi Paul and Petr,
>
> Do you know of any uses of this plugin we could learn from?
>
> Best regards,
> Brian
>
> On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan at redhat.com <mailto:kkhan at redhat.com>> wrote:
>
>     Perhaps https://github.com/jboss/bom-builder-maven-plugin <https://github.com/jboss/bom-builder-maven-plugin> can be used?
>     I've not played with it
>
>     > On 4 May 2018, at 22:11, David Lloyd <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>> wrote:
>     >
>     > I've created https://issues.jboss.org/browse/WFLY-10330 <https://issues.jboss.org/browse/WFLY-10330> and
>     > https://issues.jboss.org/browse/WFCORE-3803 <https://issues.jboss.org/browse/WFCORE-3803> to track this.
>     >
>     > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
>     >> I agree. We can break the bom cycle a different way.
>     >>
>     >>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>> wrote:
>     >>>
>     >>> I propose we revert the component-matrix change.? This change is
>     >>> ostensibly to help in the creation of a BOM for the client libraries
>     >>> and other dependent projects; however, the cost has turned out to be
>     >>> somewhat higher than expected.
>     >>>
>     >>> IntelliJ seems to be unable to cope with dependency changes in the
>     >>> project due to the use of import from the root POM.? This means that
>     >>> the entire project must be force-reimported from time to time to keep
>     >>> dependencies up to date, and forgetting to do so can lead to
>     >>> development issues and lost time.
>     >>>
>     >>> Also, I've observed that Maven itself does not always correctly
>     >>> resolve versions anymore, when you're building from a submodule.? I
>     >>> don't really know why this is the case but I suspect that it's due to
>     >>> some algorithmic ambiguity when the dependency tree is not linear like
>     >>> it used to be.
>     >>>
>     >>> I think that if we need to generate some BOM for use by external
>     >>> projects, it should be done as a separate step and artifact which
>     >>> acquires versions from the parent.? I believe we had it this way at
>     >>> one point, didn't we?
>     >>>
>     >>> Anyway I think this change didn't work out, and we should undo it
>     >>> while it's still remotely possible. WDYT?
>     >>>
>     >>> --
>     >>> - 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>
>     >
>     >
>     >
>     > --
>     > - 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>
>
>
>     _______________________________________________
>     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/20180509/e56a4df7/attachment.html 

From tom.jenkinson at redhat.com  Wed May  9 03:39:04 2018
From: tom.jenkinson at redhat.com (Tom Jenkinson)
Date: Wed, 9 May 2018 08:39:04 +0100
Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan
 Openshift Template
In-Reply-To: <CAPhbRDZVzXdsc8SGOFGbBQiW8Kwz5BeFDv-Wirm-Q_R-dxqO7Q@mail.gmail.com>
References: <CAFm4XO1sd48hcd76PF6THjXpExzKoHC=GgU7BwEUnwRV8o=avw@mail.gmail.com>
	<CAA9R9O77sdZA3b=AXudPmBUrfZXYJXU+3+KGzeV7H=BJ=7PcNQ@mail.gmail.com>
	<CAFm4XO1Ld81pjqfvw7G+EXit+uYkkJKtzpi=fYvkh1Sr-hhofw@mail.gmail.com>
	<CAA9R9O6ZfZ3HzpOQs0dnNvrvGB0tPR_T9qZSvCh1aaKP3qjotw@mail.gmail.com>
	<CAFMDs3DFJZd5LkhVwhzdyTQ15VskgcRgCLiAgAc5rkCDwdpVhQ@mail.gmail.com>
	<CAA9R9O77t21M=D8bMoQp7HsvHMsTQO2J_+k_iKgKQucNLZWeMA@mail.gmail.com>
	<CALaezvUOXKEE87iTagAnE-Dnx2SYGefmGOTbVkih0R_X-HuUQQ@mail.gmail.com>
	<CAA9R9O6HJk+CAC7X4QG07zO3Wtq8=rVq9we5UCKUmywjVENZ2A@mail.gmail.com>
	<CALaezvVJLuv4OYqdKk73gNLPiUyE2h-FQtU5dF8xfc-7XFPaFg@mail.gmail.com>
	<CAA9R9O7rYHmN6zSk+oP43Je3a4DQBjZw_+Ox9RmG5HbH5WnBag@mail.gmail.com>
	<CALaezvVTZxFDo+auOALk3tjXC1nkTShZuZu5364GQFSNrcPFtg@mail.gmail.com>
	<CAA9R9O4rb+VqbgTWppg0TK+_J9W=3xVrs+ac1gnO1MoCTXFoEw@mail.gmail.com>
	<CAPhbRDaTN4T3KvPud8Rk45m-b_C=1KhasahO4_uJqqBz1f_=Vw@mail.gmail.com>
	<CALaezvUUXYwrhPRNXF-CVQgv7EEYVFW3YrTs=5wabBN9rtsyBg@mail.gmail.com>
	<CAPhbRDbEbZ3ggVNKYN32f-KnmAA3vC9_q3BXeJuKEXpaSfjDuA@mail.gmail.com>
	<CALaezvWO_q0ghyRNmhr2e3D4RwRUo9pY+nbwBannEy+YYnR0nw@mail.gmail.com>
	<CAPhbRDZVzXdsc8SGOFGbBQiW8Kwz5BeFDv-Wirm-Q_R-dxqO7Q@mail.gmail.com>
Message-ID: <CALaezvV_A7QfF6ahiuajO_wEAA2JvDaH2k3bOQjugj2LUw6Hdw@mail.gmail.com>

Thanks Brian. Does it work for you Sebastian?

On 8 May 2018 at 23:05, Brian Stansberry <brian.stansberry at redhat.com>
wrote:

> Ah, ok. I was thinking of scripting in the broad sense the various stuff
> that goes into creating images.
>
> In any case, I don't see any downside to having node-identifier="${jbos
> s.tx.node.id:1}" in the standard WF config files.
>
>
>
> On Tue, May 8, 2018 at 3:07 PM, Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
>
>> I think they want to avoid changing the standalone.xml file and just want
>> to control it from their startup script.
>>
>> On 8 May 2018 at 18:45, Brian Stansberry <brian.stansberry at redhat.com>
>> wrote:
>>
>>> I might have missed something along the way, but if they are going to do
>>> scripting wouldn't they just set the attribute to ${jboss.node.name}
>>> and count on the fact that this is unique per pod?
>>>
>>> On Tue, May 8, 2018 at 3:28 AM, Tom Jenkinson <tom.jenkinson at redhat.com>
>>> wrote:
>>>
>>>> Thanks for confirming Brian.
>>>>
>>>> Perhaps we could set it to:
>>>> node-identifier="${jboss.tx.node.id:1}"
>>>> (a bit like https://github.com/jboss-developer/jboss-eap-quickstart
>>>> s/tree/7.1/jts)
>>>>
>>>> Sebastian could set -Djboss.tx.node.id during startup in a script?
>>>>
>>>>
>>>>
>>>> On 7 May 2018 at 22:08, Brian Stansberry <brian.stansberry at redhat.com>
>>>> wrote:
>>>>
>>>>> If it's not already set, WildFly sets the system property
>>>>> jboss.node.name at the very beginning of server boot, so ${
>>>>> jboss.node.name*:1*} would not resolve to 1.
>>>>>
>>>>> On Sun, May 6, 2018 at 6:10 PM, Sebastian Laskawiec <
>>>>> slaskawi at redhat.com> wrote:
>>>>>
>>>>>> Ok, so how about doing the same thing you suggested, but just more
>>>>>> explicitly - adding node-identifier="${jboss.node.name*:1*}". This
>>>>>> way the bare metal deployment should be happy (since the default is still
>>>>>> 1) and we wouldn't need to override it in Infinispan.
>>>>>>
>>>>>> On Tue, May 1, 2018 at 10:09 AM Tom Jenkinson <
>>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>>
>>>>>>> I am not sure - the default should be "1" for the bare metal case so
>>>>>>> the warning is reliably triggered but the default can be the pod name for
>>>>>>> OpenShift templates that only allow a single instance of the application
>>>>>>> server - does that help?
>>>>>>>
>>>>>>> The file you looked to want to edit is shared by bare metal and
>>>>>>> other deployment environments so it would be confusing to set the default
>>>>>>> to jboss.node.name there IMO.
>>>>>>>
>>>>>>> On 1 May 2018 at 03:39, Sebastian Laskawiec <slaskawi at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Fair enough Tom. Thanks for explanation.
>>>>>>>>
>>>>>>>> One more request - would you guys be OK with me adding
>>>>>>>> a node-identifier="${jboss.node.name}" to the transaction
>>>>>>>> subsystem template [1]? This way we wouldn't need to copy it into
>>>>>>>> Infinispan (since we need to set it).
>>>>>>>>
>>>>>>>> [1] https://github.com/wildfly/wildfly/blob/master/transacti
>>>>>>>> ons/src/main/resources/subsystem-templates/transactions.xml#L6
>>>>>>>>
>>>>>>>> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson <
>>>>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec <
>>>>>>>>> slaskawi at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hey Tom,
>>>>>>>>>>
>>>>>>>>>> Comments inlined.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Sebastian
>>>>>>>>>>
>>>>>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson <
>>>>>>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 16 April 2018 at 09:31, <> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Adding +WildFly Dev <wildfly-dev at lists.jboss.org> to the
>>>>>>>>>>>> loop
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the explanation Rado.
>>>>>>>>>>>>
>>>>>>>>>>>> TL;DR: A while ago Sanne pointed out that we do not set
>>>>>>>>>>>> `node-identifier`
>>>>>>>>>>>> in transaction subsystem by default. The default value for the
>>>>>>>>>>>> `node-identifier` attribute it `1`. Not setting this attribute
>>>>>>>>>>>> might cause
>>>>>>>>>>>> problems in transaction recovery. Perhaps we could follow
>>>>>>>>>>>> Rado's idea and
>>>>>>>>>>>> set it to node name by default?
>>>>>>>>>>>>
>>>>>>>>>>> Indeed - it would cause serious data integrity problems if a
>>>>>>>>>>> non-unique node-identifier is used.
>>>>>>>>>>>
>>>>>>>>>>>> Some more comments inlined.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar <rhusar at
>>>>>>>>>>>> redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> > Hi Sebastian,
>>>>>>>>>>>> >
>>>>>>>>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec
>>>>>>>>>>>> > <slaskawi at redhat.com> wrote:
>>>>>>>>>>>> > > Hey Rado, Paul,
>>>>>>>>>>>> > >
>>>>>>>>>>>> > > I started looking into this issue and it turned out that WF
>>>>>>>>>>>> subsystem
>>>>>>>>>>>> > > template doesn't provide `node-identifier` attribute [1].
>>>>>>>>>>>> >
>>>>>>>>>>>> > I assume you mean that the default WildFly server profiles do
>>>>>>>>>>>> not
>>>>>>>>>>>>
>>>>>>>>>>> > explicitly define the attribute. Right ? thus the value
>>>>>>>>>>>> defaults in
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> > the model to "1"
>>>>>>>>>>>> >
>>>>>>>>>>>> > https://github.com/wildfly/wildfly/blob/master/transactions/
>>>>>>>>>>>> src/main/java/org/jboss/as/txn/subsystem/TransactionSubsyste
>>>>>>>>>>>> mRootResourceDefinition.java#L97
>>>>>>>>>>>> > which sole intention seems to be to log a warning on boot if
>>>>>>>>>>>> the value
>>>>>>>>>>>> > is unchanged.
>>>>>>>>>>>> > Why they decided on a constant that will be inherently not
>>>>>>>>>>>> unique as
>>>>>>>>>>>> > opposed to defaulting to the node name (which we already
>>>>>>>>>>>> require to be
>>>>>>>>>>>> > unique) as clustering node name or undertow instance-id does,
>>>>>>>>>>>> is
>>>>>>>>>>>> > unclear to me.
>>>>>>>>>>>> > Some context is on https://issues.jboss.org/browse/WFLY-1119.
>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>> In OpenShift environment we could set it to `hostname`. This is
>>>>>>>>>>>> guaranteed
>>>>>>>>>>>> to be unique in whole OpenShift cluster.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> We do this too in EAP images.
>>>>>>>>>>> To Rado's point, the default is "1" so we can print the warning
>>>>>>>>>>> to alert people they are misconfigured - it seems to be working :)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This is the point. From my understanding, if we set it to node
>>>>>>>>>> name (instead of "1"), we could make it always work correctly. We could
>>>>>>>>>> even remove the code that emits the warning (since the node name needs to
>>>>>>>>>> be unique).
>>>>>>>>>>
>>>>>>>>>> To sum it up - if we decided to proceed this way, there would be
>>>>>>>>>> no requirement of setting the node-identifier at all.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> For OpenShift you are right there is no requirement for someone to
>>>>>>>>> change the node-identifier from the podname and so that is why EAP images
>>>>>>>>> do that.
>>>>>>>>>
>>>>>>>>> For bare-metal it is different as there can be two servers on the
>>>>>>>>> same machine so they were configured to use the hostname as they
>>>>>>>>> node-identifier then if they were also connected to the same resource
>>>>>>>>> managers or the same object store they would interfere with each other.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> > > I'm not sure if you guys are the right people to ask, but
>>>>>>>>>>>> is it safe to
>>>>>>>>>>>> > > leave it set to default? Or shall I override our Infinispan
>>>>>>>>>>>> templates and
>>>>>>>>>>>> > > add this parameter (as I mentioned before, in OpenShift
>>>>>>>>>>>> this I wanted to
>>>>>>>>>>>> > set
>>>>>>>>>>>> > > it as Pod name trimmed to the last 23 chars since this is
>>>>>>>>>>>> the limit).
>>>>>>>>>>>>
>>>>>>>>>>> Putting a response to this in line - I am not certain who
>>>>>>>>>>> originally proposed this.
>>>>>>>>>>>
>>>>>>>>>>> You must use a globally unique node-identifier. If you are
>>>>>>>>>>> certain the last 23 characters guarantee that it would be valid - if there
>>>>>>>>>>> is a chance they are not unique it is not valid to trim.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If that's not an issue, again, we could use the same limit as we
>>>>>>>>>> have for node name.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> > It is not safe to leave it set to "1" as that results in
>>>>>>>>>>>> inconsistent
>>>>>>>>>>>> > processing of transaction recovery.
>>>>>>>>>>>> > IIUC we already set it to the node name for both EAP and JDG
>>>>>>>>>>>> >
>>>>>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/master/os
>>>>>>>>>>>> -eap70-openshift/added/standalone-openshift.xml#L411
>>>>>>>>>>>> >
>>>>>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/master/os
>>>>>>>>>>>> -jdg7-conffiles/added/clustered-openshift.xml#L282
>>>>>>>>>>>>
>>>>>>>>>>> > which in turn defaults to the pod name ? so which profiles are
>>>>>>>>>>>> we
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> > talking about here?
>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>> Granted, we set it by default in CCT Modules. However in
>>>>>>>>>>>> Infinispan we just
>>>>>>>>>>>> grab provided transaction subsystem when rendering full
>>>>>>>>>>>> configuration from
>>>>>>>>>>>> featurepacks:
>>>>>>>>>>>> https://github.com/infinispan/infinispan/blob/master/server/
>>>>>>>>>>>> integration/feature-pack/src/main/resources/configuration/st
>>>>>>>>>>>> andalone/subsystems-cloud.xml#L19
>>>>>>>>>>>>
>>>>>>>>>>>> The default configuration XML doesn't contain the
>>>>>>>>>>>> `node-identifier`
>>>>>>>>>>>> attribute. I can add it manually in the cloud.xml but I believe
>>>>>>>>>>>> the right
>>>>>>>>>>>> approach is to modify the transaction subsystem.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> > Rado
>>>>>>>>>>>> >
>>>>>>>>>>>> > > Thanks,
>>>>>>>>>>>> > > Seb
>>>>>>>>>>>> > >
>>>>>>>>>>>> > > [1] usually set to node-identifier="${jboss.node.name}"
>>>>>>>>>>>> > >
>>>>>>>>>>>> > >
>>>>>>>>>>>>
>>>>>>>>>>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero <sanne at
>>>>>>>>>>>> infinispan.org>
>>>>>>>>>>>> > > wrote:
>>>>>>>>>>>> > >>
>>>>>>>>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec <slaskawi at
>>>>>>>>>>>> redhat.com>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> > wrote:
>>>>>>>>>>>> > >> > Thanks for looking into it Sanne. Of course, we should
>>>>>>>>>>>> add it (it can
>>>>>>>>>>>> > be
>>>>>>>>>>>> > >> > set
>>>>>>>>>>>> > >> > to the same name as hostname since those are unique in
>>>>>>>>>>>> Kubernetes).
>>>>>>>>>>>> > >> >
>>>>>>>>>>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 for
>>>>>>>>>>>> it.
>>>>>>>>>>>> > >> >
>>>>>>>>>>>> > >> > Thanks again!
>>>>>>>>>>>> > >> > Seb
>>>>>>>>>>>> > >>
>>>>>>>>>>>> > >> Thanks Sebastian!
>>>>>>>>>>>> > >>
>>>>>>>>>>>> > >> >
>>>>>>>>>>>>
>>>>>>>>>>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero <sanne at
>>>>>>>>>>>> infinispan.org>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> > >> > wrote:
>>>>>>>>>>>> > >> >>
>>>>>>>>>>>> > >> >> Hi all,
>>>>>>>>>>>> > >> >>
>>>>>>>>>>>> > >> >> I've started to use the Infinispan Openshift Template
>>>>>>>>>>>> and was
>>>>>>>>>>>> > browsing
>>>>>>>>>>>> > >> >> through the errors and warnings this produces.
>>>>>>>>>>>> > >> >>
>>>>>>>>>>>> > >> >> In particular I noticed "WFLYTX0013: Node identifier
>>>>>>>>>>>> property is set
>>>>>>>>>>>> > >> >> to the default value. Please make sure it is unique."
>>>>>>>>>>>> being produced
>>>>>>>>>>>> > >> >> by the transaction system.
>>>>>>>>>>>> > >> >>
>>>>>>>>>>>> > >> >> The node id is usually not needed for developer's
>>>>>>>>>>>> convenience and
>>>>>>>>>>>> > >> >> assuming there's a single node in "dev mode", yet
>>>>>>>>>>>> clearly the
>>>>>>>>>>>> > >> >> Infinispan template is meant to work with multiple
>>>>>>>>>>>> nodes running so
>>>>>>>>>>>> > >> >> this warning seems concerning.
>>>>>>>>>>>> > >> >>
>>>>>>>>>>>> > >> >> I'm not sure what the impact is on the transaction
>>>>>>>>>>>> manager so I asked
>>>>>>>>>>>> > >> >> on the Narayana forums; Tom pointed me to some
>>>>>>>>>>>> thourough design
>>>>>>>>>>>> > >> >> documents and also suggested the EAP image does set the
>>>>>>>>>>>> node
>>>>>>>>>>>> > >> >> identifier:
>>>>>>>>>>>> > >> >>  - https://developer.jboss.org/message/981702#981702
>>>>>>>>>>>> > >> >>
>>>>>>>>>>>> > >> >> WDYT? we probably want the Infinispan template to set
>>>>>>>>>>>> this as well,
>>>>>>>>>>>> > or
>>>>>>>>>>>> > >> >> silence the warning?
>>>>>>>>>>>> > >> >>
>>>>>>>>>>>> > >> >> Thanks,
>>>>>>>>>>>> > >> >> Sanne
>>>>>>>>>>>> > >> >> _______________________________________________
>>>>>>>>>>>> > >> >> infinispan-dev mailing list
>>>>>>>>>>>>
>>>>>>>>>>> > >> >> infinispan-dev at lists.jboss.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>>>>> > >> >
>>>>>>>>>>>> > >> >
>>>>>>>>>>>> > >> > _______________________________________________
>>>>>>>>>>>> > >> > infinispan-dev mailing list
>>>>>>>>>>>>
>>>>>>>>>>> > >> > infinispan-dev at lists.jboss.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> > >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>>>>> > >> _______________________________________________
>>>>>>>>>>>> > >> infinispan-dev mailing list
>>>>>>>>>>>> > >> infinispan-dev at lists.jboss.org
>>>>>>>>>>>> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>>>>> >
>>>>>>>>>>>> -------------- next part --------------
>>>>>>>>>>>> An HTML attachment was scrubbed...
>>>>>>>>>>>> URL: http://lists.jboss.org/piperma
>>>>>>>>>>>> il/wildfly-dev/attachments/20180416/65962cf1/attachment-0001
>>>>>>>>>>>> .html
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20180509/1f924419/attachment-0001.html 

From emartins at redhat.com  Wed May  9 08:11:02 2018
From: emartins at redhat.com (Eduardo Martins)
Date: Wed, 9 May 2018 13:11:02 +0100
Subject: [wildfly-dev] Proposal to revert component-matrix change
In-Reply-To: <2D720673-FE26-4A9C-A863-CF2614DC0833@redhat.com>
References: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
	<CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>
	<CANghgrQ5Tv9iprCBtbcP-XjF7S9pFSp1WztRHYYg7h1MYpyNhw@mail.gmail.com>
	<E44D4A57-C2A1-4B45-98AA-D90C56F82B24@redhat.com>
	<CACa2xU8VE4xez2Ui5zVgtOV2UrPt35bvGpAbhPRTGi9RH_+xpQ@mail.gmail.com>
	<2D720673-FE26-4A9C-A863-CF2614DC0833@redhat.com>
Message-ID: <327DB6D0-B20D-4AF9-B136-533A69E71F45@redhat.com>

It turns out that the component-matrix was never added to Quickstarts, nothing to revert there.

?E


> On 08 May 2018, at 16:12, Eduardo Martins <emartins at redhat.com> wrote:
> 
> We also revert back to what we had before in QS, and work out a better solution from there.
> 
> ?E
> 
>> On 08 May 2018, at 16:06, Rostislav Svoboda <rsvoboda at redhat.com <mailto:rsvoboda at redhat.com>> wrote:
>> 
>> Tomaz mentioned Quickstarts as one of the reasons to have BOMs in WF and WF-CORE.
>> 
>> Eduardo should confirm that revert is fine for QS.
>> 
>> Rostislav
>> 
>> On Sat, May 5, 2018 at 11:25 AM, Kabir Khan <kkhan at redhat.com <mailto:kkhan at redhat.com>> wrote:
>> Perhaps https://github.com/jboss/bom-builder-maven-plugin <https://github.com/jboss/bom-builder-maven-plugin> can be used? I've not played with it
>> 
>> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>> wrote:
>> > 
>> > I've created https://issues.jboss.org/browse/WFLY-10330 <https://issues.jboss.org/browse/WFLY-10330> and
>> > https://issues.jboss.org/browse/WFCORE-3803 <https://issues.jboss.org/browse/WFCORE-3803> to track this.
>> > 
>> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene at redhat.com <mailto:jason.greene at redhat.com>> wrote:
>> >> I agree. We can break the bom cycle a different way.
>> >> 
>> >>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd at redhat.com <mailto:david.lloyd at redhat.com>> wrote:
>> >>> 
>> >>> I propose we revert the component-matrix change.  This change is
>> >>> ostensibly to help in the creation of a BOM for the client libraries
>> >>> and other dependent projects; however, the cost has turned out to be
>> >>> somewhat higher than expected.
>> >>> 
>> >>> IntelliJ seems to be unable to cope with dependency changes in the
>> >>> project due to the use of import from the root POM.  This means that
>> >>> the entire project must be force-reimported from time to time to keep
>> >>> dependencies up to date, and forgetting to do so can lead to
>> >>> development issues and lost time.
>> >>> 
>> >>> Also, I've observed that Maven itself does not always correctly
>> >>> resolve versions anymore, when you're building from a submodule.  I
>> >>> don't really know why this is the case but I suspect that it's due to
>> >>> some algorithmic ambiguity when the dependency tree is not linear like
>> >>> it used to be.
>> >>> 
>> >>> I think that if we need to generate some BOM for use by external
>> >>> projects, it should be done as a separate step and artifact which
>> >>> acquires versions from the parent.  I believe we had it this way at
>> >>> one point, didn't we?
>> >>> 
>> >>> Anyway I think this change didn't work out, and we should undo it
>> >>> while it's still remotely possible.  WDYT?
>> >>> 
>> >>> --
>> >>> - 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>
>> > 
>> > 
>> > 
>> > -- 
>> > - 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>
>> 
>> 
>> _______________________________________________
>> 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>
>> 
> 

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

From slaskawi at redhat.com  Wed May  9 21:56:41 2018
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Thu, 10 May 2018 01:56:41 +0000
Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan
 Openshift Template
In-Reply-To: <CALaezvV_A7QfF6ahiuajO_wEAA2JvDaH2k3bOQjugj2LUw6Hdw@mail.gmail.com>
References: <CAFm4XO1sd48hcd76PF6THjXpExzKoHC=GgU7BwEUnwRV8o=avw@mail.gmail.com>
	<CAA9R9O77sdZA3b=AXudPmBUrfZXYJXU+3+KGzeV7H=BJ=7PcNQ@mail.gmail.com>
	<CAFm4XO1Ld81pjqfvw7G+EXit+uYkkJKtzpi=fYvkh1Sr-hhofw@mail.gmail.com>
	<CAA9R9O6ZfZ3HzpOQs0dnNvrvGB0tPR_T9qZSvCh1aaKP3qjotw@mail.gmail.com>
	<CAFMDs3DFJZd5LkhVwhzdyTQ15VskgcRgCLiAgAc5rkCDwdpVhQ@mail.gmail.com>
	<CAA9R9O77t21M=D8bMoQp7HsvHMsTQO2J_+k_iKgKQucNLZWeMA@mail.gmail.com>
	<CALaezvUOXKEE87iTagAnE-Dnx2SYGefmGOTbVkih0R_X-HuUQQ@mail.gmail.com>
	<CAA9R9O6HJk+CAC7X4QG07zO3Wtq8=rVq9we5UCKUmywjVENZ2A@mail.gmail.com>
	<CALaezvVJLuv4OYqdKk73gNLPiUyE2h-FQtU5dF8xfc-7XFPaFg@mail.gmail.com>
	<CAA9R9O7rYHmN6zSk+oP43Je3a4DQBjZw_+Ox9RmG5HbH5WnBag@mail.gmail.com>
	<CALaezvVTZxFDo+auOALk3tjXC1nkTShZuZu5364GQFSNrcPFtg@mail.gmail.com>
	<CAA9R9O4rb+VqbgTWppg0TK+_J9W=3xVrs+ac1gnO1MoCTXFoEw@mail.gmail.com>
	<CAPhbRDaTN4T3KvPud8Rk45m-b_C=1KhasahO4_uJqqBz1f_=Vw@mail.gmail.com>
	<CALaezvUUXYwrhPRNXF-CVQgv7EEYVFW3YrTs=5wabBN9rtsyBg@mail.gmail.com>
	<CAPhbRDbEbZ3ggVNKYN32f-KnmAA3vC9_q3BXeJuKEXpaSfjDuA@mail.gmail.com>
	<CALaezvWO_q0ghyRNmhr2e3D4RwRUo9pY+nbwBannEy+YYnR0nw@mail.gmail.com>
	<CAPhbRDZVzXdsc8SGOFGbBQiW8Kwz5BeFDv-Wirm-Q_R-dxqO7Q@mail.gmail.com>
	<CALaezvV_A7QfF6ahiuajO_wEAA2JvDaH2k3bOQjugj2LUw6Hdw@mail.gmail.com>
Message-ID: <CAA9R9O6pH80g+1CCv2iOKQUc8FrGxh==xfkG9_GRB5m-gdMGEw@mail.gmail.com>

I'm sorry for delay... I got sucked by the Summit prep activities.

Yes, to all, what you said! Shall I create a JIRA for you?



On Wed, May 9, 2018 at 9:39 AM Tom Jenkinson <tom.jenkinson at redhat.com>
wrote:

> Thanks Brian. Does it work for you Sebastian?
>
> On 8 May 2018 at 23:05, Brian Stansberry <brian.stansberry at redhat.com>
> wrote:
>
>> Ah, ok. I was thinking of scripting in the broad sense the various stuff
>> that goes into creating images.
>>
>> In any case, I don't see any downside to having node-identifier="${
>> jboss.tx.node.id:1}" in the standard WF config files.
>>
>>
>>
>> On Tue, May 8, 2018 at 3:07 PM, Tom Jenkinson <tom.jenkinson at redhat.com>
>> wrote:
>>
>>> I think they want to avoid changing the standalone.xml file and just
>>> want to control it from their startup script.
>>>
>>> On 8 May 2018 at 18:45, Brian Stansberry <brian.stansberry at redhat.com>
>>> wrote:
>>>
>>>> I might have missed something along the way, but if they are going to
>>>> do scripting wouldn't they just set the attribute to ${jboss.node.name}
>>>> and count on the fact that this is unique per pod?
>>>>
>>>> On Tue, May 8, 2018 at 3:28 AM, Tom Jenkinson <tom.jenkinson at redhat.com
>>>> > wrote:
>>>>
>>>>> Thanks for confirming Brian.
>>>>>
>>>>> Perhaps we could set it to:
>>>>> node-identifier="${jboss.tx.node.id:1}"
>>>>> (a bit like
>>>>> https://github.com/jboss-developer/jboss-eap-quickstarts/tree/7.1/jts)
>>>>>
>>>>> Sebastian could set -Djboss.tx.node.id during startup in a script?
>>>>>
>>>>>
>>>>>
>>>>> On 7 May 2018 at 22:08, Brian Stansberry <brian.stansberry at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> If it's not already set, WildFly sets the system property
>>>>>> jboss.node.name at the very beginning of server boot, so ${
>>>>>> jboss.node.name*:1*} would not resolve to 1.
>>>>>>
>>>>>> On Sun, May 6, 2018 at 6:10 PM, Sebastian Laskawiec <
>>>>>> slaskawi at redhat.com> wrote:
>>>>>>
>>>>>>> Ok, so how about doing the same thing you suggested, but just more
>>>>>>> explicitly - adding node-identifier="${jboss.node.name*:1*}". This
>>>>>>> way the bare metal deployment should be happy (since the default is still
>>>>>>> 1) and we wouldn't need to override it in Infinispan.
>>>>>>>
>>>>>>> On Tue, May 1, 2018 at 10:09 AM Tom Jenkinson <
>>>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>>>
>>>>>>>> I am not sure - the default should be "1" for the bare metal case
>>>>>>>> so the warning is reliably triggered but the default can be the pod name
>>>>>>>> for OpenShift templates that only allow a single instance of the
>>>>>>>> application server - does that help?
>>>>>>>>
>>>>>>>> The file you looked to want to edit is shared by bare metal and
>>>>>>>> other deployment environments so it would be confusing to set the default
>>>>>>>> to jboss.node.name there IMO.
>>>>>>>>
>>>>>>>> On 1 May 2018 at 03:39, Sebastian Laskawiec <slaskawi at redhat.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Fair enough Tom. Thanks for explanation.
>>>>>>>>>
>>>>>>>>> One more request - would you guys be OK with me adding
>>>>>>>>> a node-identifier="${jboss.node.name}" to the transaction
>>>>>>>>> subsystem template [1]? This way we wouldn't need to copy it into
>>>>>>>>> Infinispan (since we need to set it).
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/resources/subsystem-templates/transactions.xml#L6
>>>>>>>>>
>>>>>>>>> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson <
>>>>>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>>>>>
>>>>>>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec <
>>>>>>>>>> slaskawi at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hey Tom,
>>>>>>>>>>>
>>>>>>>>>>> Comments inlined.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Sebastian
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson <
>>>>>>>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 16 April 2018 at 09:31, <> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Adding +WildFly Dev <wildfly-dev at lists.jboss.org> to the
>>>>>>>>>>>>> loop
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for the explanation Rado.
>>>>>>>>>>>>>
>>>>>>>>>>>>> TL;DR: A while ago Sanne pointed out that we do not set
>>>>>>>>>>>>> `node-identifier`
>>>>>>>>>>>>> in transaction subsystem by default. The default value for the
>>>>>>>>>>>>> `node-identifier` attribute it `1`. Not setting this attribute
>>>>>>>>>>>>> might cause
>>>>>>>>>>>>> problems in transaction recovery. Perhaps we could follow
>>>>>>>>>>>>> Rado's idea and
>>>>>>>>>>>>> set it to node name by default?
>>>>>>>>>>>>>
>>>>>>>>>>>> Indeed - it would cause serious data integrity problems if a
>>>>>>>>>>>> non-unique node-identifier is used.
>>>>>>>>>>>>
>>>>>>>>>>>>> Some more comments inlined.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar <rhusar at
>>>>>>>>>>>>> redhat.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> > Hi Sebastian,
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec
>>>>>>>>>>>>> > <slaskawi at redhat.com> wrote:
>>>>>>>>>>>>> > > Hey Rado, Paul,
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > I started looking into this issue and it turned out that
>>>>>>>>>>>>> WF subsystem
>>>>>>>>>>>>> > > template doesn't provide `node-identifier` attribute [1].
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > I assume you mean that the default WildFly server profiles
>>>>>>>>>>>>> do not
>>>>>>>>>>>>>
>>>>>>>>>>>> > explicitly define the attribute. Right ? thus the value
>>>>>>>>>>>>> defaults in
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> > the model to "1"
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >
>>>>>>>>>>>>> https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/subsystem/TransactionSubsystemRootResourceDefinition.java#L97
>>>>>>>>>>>>> > which sole intention seems to be to log a warning on boot if
>>>>>>>>>>>>> the value
>>>>>>>>>>>>> > is unchanged.
>>>>>>>>>>>>> > Why they decided on a constant that will be inherently not
>>>>>>>>>>>>> unique as
>>>>>>>>>>>>> > opposed to defaulting to the node name (which we already
>>>>>>>>>>>>> require to be
>>>>>>>>>>>>> > unique) as clustering node name or undertow instance-id
>>>>>>>>>>>>> does, is
>>>>>>>>>>>>> > unclear to me.
>>>>>>>>>>>>> > Some context is on https://issues.jboss.org/browse/WFLY-1119
>>>>>>>>>>>>> .
>>>>>>>>>>>>> >
>>>>>>>>>>>>>
>>>>>>>>>>>>> In OpenShift environment we could set it to `hostname`. This
>>>>>>>>>>>>> is guaranteed
>>>>>>>>>>>>> to be unique in whole OpenShift cluster.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> We do this too in EAP images.
>>>>>>>>>>>> To Rado's point, the default is "1" so we can print the warning
>>>>>>>>>>>> to alert people they are misconfigured - it seems to be working :)
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This is the point. From my understanding, if we set it to node
>>>>>>>>>>> name (instead of "1"), we could make it always work correctly. We could
>>>>>>>>>>> even remove the code that emits the warning (since the node name needs to
>>>>>>>>>>> be unique).
>>>>>>>>>>>
>>>>>>>>>>> To sum it up - if we decided to proceed this way, there would be
>>>>>>>>>>> no requirement of setting the node-identifier at all.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> For OpenShift you are right there is no requirement for someone
>>>>>>>>>> to change the node-identifier from the podname and so that is why EAP
>>>>>>>>>> images do that.
>>>>>>>>>>
>>>>>>>>>> For bare-metal it is different as there can be two servers on the
>>>>>>>>>> same machine so they were configured to use the hostname as they
>>>>>>>>>> node-identifier then if they were also connected to the same resource
>>>>>>>>>> managers or the same object store they would interfere with each other.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> > > I'm not sure if you guys are the right people to ask, but
>>>>>>>>>>>>> is it safe to
>>>>>>>>>>>>> > > leave it set to default? Or shall I override our
>>>>>>>>>>>>> Infinispan templates and
>>>>>>>>>>>>> > > add this parameter (as I mentioned before, in OpenShift
>>>>>>>>>>>>> this I wanted to
>>>>>>>>>>>>> > set
>>>>>>>>>>>>> > > it as Pod name trimmed to the last 23 chars since this is
>>>>>>>>>>>>> the limit).
>>>>>>>>>>>>>
>>>>>>>>>>>> Putting a response to this in line - I am not certain who
>>>>>>>>>>>> originally proposed this.
>>>>>>>>>>>>
>>>>>>>>>>>> You must use a globally unique node-identifier. If you are
>>>>>>>>>>>> certain the last 23 characters guarantee that it would be valid - if there
>>>>>>>>>>>> is a chance they are not unique it is not valid to trim.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If that's not an issue, again, we could use the same limit as we
>>>>>>>>>>> have for node name.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> > It is not safe to leave it set to "1" as that results in
>>>>>>>>>>>>> inconsistent
>>>>>>>>>>>>> > processing of transaction recovery.
>>>>>>>>>>>>> > IIUC we already set it to the node name for both EAP and JDG
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >
>>>>>>>>>>>>> https://github.com/jboss-openshift/cct_module/blob/master/os-eap70-openshift/added/standalone-openshift.xml#L411
>>>>>>>>>>>>> >
>>>>>>>>>>>>> >
>>>>>>>>>>>>> https://github.com/jboss-openshift/cct_module/blob/master/os-jdg7-conffiles/added/clustered-openshift.xml#L282
>>>>>>>>>>>>>
>>>>>>>>>>>> > which in turn defaults to the pod name ? so which profiles
>>>>>>>>>>>>> are we
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> > talking about here?
>>>>>>>>>>>>> >
>>>>>>>>>>>>>
>>>>>>>>>>>>> Granted, we set it by default in CCT Modules. However in
>>>>>>>>>>>>> Infinispan we just
>>>>>>>>>>>>> grab provided transaction subsystem when rendering full
>>>>>>>>>>>>> configuration from
>>>>>>>>>>>>> featurepacks:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://github.com/infinispan/infinispan/blob/master/server/integration/feature-pack/src/main/resources/configuration/standalone/subsystems-cloud.xml#L19
>>>>>>>>>>>>>
>>>>>>>>>>>>> The default configuration XML doesn't contain the
>>>>>>>>>>>>> `node-identifier`
>>>>>>>>>>>>> attribute. I can add it manually in the cloud.xml but I
>>>>>>>>>>>>> believe the right
>>>>>>>>>>>>> approach is to modify the transaction subsystem.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> > Rado
>>>>>>>>>>>>> >
>>>>>>>>>>>>> > > Thanks,
>>>>>>>>>>>>> > > Seb
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > > [1] usually set to node-identifier="${jboss.node.name}"
>>>>>>>>>>>>> > >
>>>>>>>>>>>>> > >
>>>>>>>>>>>>>
>>>>>>>>>>>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero <sanne at
>>>>>>>>>>>>> infinispan.org>
>>>>>>>>>>>>> > > wrote:
>>>>>>>>>>>>> > >>
>>>>>>>>>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec <slaskawi
>>>>>>>>>>>>> at redhat.com>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>> > >> > Thanks for looking into it Sanne. Of course, we should
>>>>>>>>>>>>> add it (it can
>>>>>>>>>>>>> > be
>>>>>>>>>>>>> > >> > set
>>>>>>>>>>>>> > >> > to the same name as hostname since those are unique in
>>>>>>>>>>>>> Kubernetes).
>>>>>>>>>>>>> > >> >
>>>>>>>>>>>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 for
>>>>>>>>>>>>> it.
>>>>>>>>>>>>> > >> >
>>>>>>>>>>>>> > >> > Thanks again!
>>>>>>>>>>>>> > >> > Seb
>>>>>>>>>>>>> > >>
>>>>>>>>>>>>> > >> Thanks Sebastian!
>>>>>>>>>>>>> > >>
>>>>>>>>>>>>> > >> >
>>>>>>>>>>>>>
>>>>>>>>>>>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero <sanne at
>>>>>>>>>>>>> infinispan.org>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> > >> > wrote:
>>>>>>>>>>>>> > >> >>
>>>>>>>>>>>>> > >> >> Hi all,
>>>>>>>>>>>>> > >> >>
>>>>>>>>>>>>> > >> >> I've started to use the Infinispan Openshift Template
>>>>>>>>>>>>> and was
>>>>>>>>>>>>> > browsing
>>>>>>>>>>>>> > >> >> through the errors and warnings this produces.
>>>>>>>>>>>>> > >> >>
>>>>>>>>>>>>> > >> >> In particular I noticed "WFLYTX0013: Node identifier
>>>>>>>>>>>>> property is set
>>>>>>>>>>>>> > >> >> to the default value. Please make sure it is unique."
>>>>>>>>>>>>> being produced
>>>>>>>>>>>>> > >> >> by the transaction system.
>>>>>>>>>>>>> > >> >>
>>>>>>>>>>>>> > >> >> The node id is usually not needed for developer's
>>>>>>>>>>>>> convenience and
>>>>>>>>>>>>> > >> >> assuming there's a single node in "dev mode", yet
>>>>>>>>>>>>> clearly the
>>>>>>>>>>>>> > >> >> Infinispan template is meant to work with multiple
>>>>>>>>>>>>> nodes running so
>>>>>>>>>>>>> > >> >> this warning seems concerning.
>>>>>>>>>>>>> > >> >>
>>>>>>>>>>>>> > >> >> I'm not sure what the impact is on the transaction
>>>>>>>>>>>>> manager so I asked
>>>>>>>>>>>>> > >> >> on the Narayana forums; Tom pointed me to some
>>>>>>>>>>>>> thourough design
>>>>>>>>>>>>> > >> >> documents and also suggested the EAP image does set
>>>>>>>>>>>>> the node
>>>>>>>>>>>>> > >> >> identifier:
>>>>>>>>>>>>> > >> >>  - https://developer.jboss.org/message/981702#981702
>>>>>>>>>>>>> > >> >>
>>>>>>>>>>>>> > >> >> WDYT? we probably want the Infinispan template to set
>>>>>>>>>>>>> this as well,
>>>>>>>>>>>>> > or
>>>>>>>>>>>>> > >> >> silence the warning?
>>>>>>>>>>>>> > >> >>
>>>>>>>>>>>>> > >> >> Thanks,
>>>>>>>>>>>>> > >> >> Sanne
>>>>>>>>>>>>> > >> >> _______________________________________________
>>>>>>>>>>>>> > >> >> infinispan-dev mailing list
>>>>>>>>>>>>>
>>>>>>>>>>>> > >> >> infinispan-dev at lists.jboss.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> > >> >>
>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>>>>>> > >> >
>>>>>>>>>>>>> > >> >
>>>>>>>>>>>>> > >> > _______________________________________________
>>>>>>>>>>>>> > >> > infinispan-dev mailing list
>>>>>>>>>>>>>
>>>>>>>>>>>> > >> > infinispan-dev at lists.jboss.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> > >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>>>>>> > >> _______________________________________________
>>>>>>>>>>>>> > >> infinispan-dev mailing list
>>>>>>>>>>>>> > >> infinispan-dev at lists.jboss.org
>>>>>>>>>>>>> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>>>>>> >
>>>>>>>>>>>>> -------------- next part --------------
>>>>>>>>>>>>> An HTML attachment was scrubbed...
>>>>>>>>>>>>> URL:
>>>>>>>>>>>>> http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180416/65962cf1/attachment-0001.html
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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/20180510/e572c406/attachment-0001.html 

From tom.jenkinson at redhat.com  Thu May 10 05:10:51 2018
From: tom.jenkinson at redhat.com (Tom Jenkinson)
Date: Thu, 10 May 2018 10:10:51 +0100
Subject: [wildfly-dev] [infinispan-dev] WFLYTX0013 in the Infinispan
 Openshift Template
In-Reply-To: <CAA9R9O6pH80g+1CCv2iOKQUc8FrGxh==xfkG9_GRB5m-gdMGEw@mail.gmail.com>
References: <CAFm4XO1sd48hcd76PF6THjXpExzKoHC=GgU7BwEUnwRV8o=avw@mail.gmail.com>
	<CAA9R9O77sdZA3b=AXudPmBUrfZXYJXU+3+KGzeV7H=BJ=7PcNQ@mail.gmail.com>
	<CAFm4XO1Ld81pjqfvw7G+EXit+uYkkJKtzpi=fYvkh1Sr-hhofw@mail.gmail.com>
	<CAA9R9O6ZfZ3HzpOQs0dnNvrvGB0tPR_T9qZSvCh1aaKP3qjotw@mail.gmail.com>
	<CAFMDs3DFJZd5LkhVwhzdyTQ15VskgcRgCLiAgAc5rkCDwdpVhQ@mail.gmail.com>
	<CAA9R9O77t21M=D8bMoQp7HsvHMsTQO2J_+k_iKgKQucNLZWeMA@mail.gmail.com>
	<CALaezvUOXKEE87iTagAnE-Dnx2SYGefmGOTbVkih0R_X-HuUQQ@mail.gmail.com>
	<CAA9R9O6HJk+CAC7X4QG07zO3Wtq8=rVq9we5UCKUmywjVENZ2A@mail.gmail.com>
	<CALaezvVJLuv4OYqdKk73gNLPiUyE2h-FQtU5dF8xfc-7XFPaFg@mail.gmail.com>
	<CAA9R9O7rYHmN6zSk+oP43Je3a4DQBjZw_+Ox9RmG5HbH5WnBag@mail.gmail.com>
	<CALaezvVTZxFDo+auOALk3tjXC1nkTShZuZu5364GQFSNrcPFtg@mail.gmail.com>
	<CAA9R9O4rb+VqbgTWppg0TK+_J9W=3xVrs+ac1gnO1MoCTXFoEw@mail.gmail.com>
	<CAPhbRDaTN4T3KvPud8Rk45m-b_C=1KhasahO4_uJqqBz1f_=Vw@mail.gmail.com>
	<CALaezvUUXYwrhPRNXF-CVQgv7EEYVFW3YrTs=5wabBN9rtsyBg@mail.gmail.com>
	<CAPhbRDbEbZ3ggVNKYN32f-KnmAA3vC9_q3BXeJuKEXpaSfjDuA@mail.gmail.com>
	<CALaezvWO_q0ghyRNmhr2e3D4RwRUo9pY+nbwBannEy+YYnR0nw@mail.gmail.com>
	<CAPhbRDZVzXdsc8SGOFGbBQiW8Kwz5BeFDv-Wirm-Q_R-dxqO7Q@mail.gmail.com>
	<CALaezvV_A7QfF6ahiuajO_wEAA2JvDaH2k3bOQjugj2LUw6Hdw@mail.gmail.com>
	<CAA9R9O6pH80g+1CCv2iOKQUc8FrGxh==xfkG9_GRB5m-gdMGEw@mail.gmail.com>
Message-ID: <CALaezvV38U6730DXjSty-=mdHpo1YgHo5zvSsZfc1FDdpRZ_9w@mail.gmail.com>

Sure - thanks!

On 10 May 2018 at 02:56, Sebastian Laskawiec <slaskawi at redhat.com> wrote:

> I'm sorry for delay... I got sucked by the Summit prep activities.
>
> Yes, to all, what you said! Shall I create a JIRA for you?
>
>
>
> On Wed, May 9, 2018 at 9:39 AM Tom Jenkinson <tom.jenkinson at redhat.com>
> wrote:
>
>> Thanks Brian. Does it work for you Sebastian?
>>
>> On 8 May 2018 at 23:05, Brian Stansberry <brian.stansberry at redhat.com>
>> wrote:
>>
>>> Ah, ok. I was thinking of scripting in the broad sense the various stuff
>>> that goes into creating images.
>>>
>>> In any case, I don't see any downside to having node-identifier="${jbos
>>> s.tx.node.id:1}" in the standard WF config files.
>>>
>>>
>>>
>>> On Tue, May 8, 2018 at 3:07 PM, Tom Jenkinson <tom.jenkinson at redhat.com>
>>> wrote:
>>>
>>>> I think they want to avoid changing the standalone.xml file and just
>>>> want to control it from their startup script.
>>>>
>>>> On 8 May 2018 at 18:45, Brian Stansberry <brian.stansberry at redhat.com>
>>>> wrote:
>>>>
>>>>> I might have missed something along the way, but if they are going to
>>>>> do scripting wouldn't they just set the attribute to ${jboss.node.name}
>>>>> and count on the fact that this is unique per pod?
>>>>>
>>>>> On Tue, May 8, 2018 at 3:28 AM, Tom Jenkinson <
>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>
>>>>>> Thanks for confirming Brian.
>>>>>>
>>>>>> Perhaps we could set it to:
>>>>>> node-identifier="${jboss.tx.node.id:1}"
>>>>>> (a bit like https://github.com/jboss-developer/jboss-eap-
>>>>>> quickstarts/tree/7.1/jts)
>>>>>>
>>>>>> Sebastian could set -Djboss.tx.node.id during startup in a script?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7 May 2018 at 22:08, Brian Stansberry <brian.stansberry at redhat.com
>>>>>> > wrote:
>>>>>>
>>>>>>> If it's not already set, WildFly sets the system property
>>>>>>> jboss.node.name at the very beginning of server boot, so ${
>>>>>>> jboss.node.name*:1*} would not resolve to 1.
>>>>>>>
>>>>>>> On Sun, May 6, 2018 at 6:10 PM, Sebastian Laskawiec <
>>>>>>> slaskawi at redhat.com> wrote:
>>>>>>>
>>>>>>>> Ok, so how about doing the same thing you suggested, but just more
>>>>>>>> explicitly - adding node-identifier="${jboss.node.name*:1*}". This
>>>>>>>> way the bare metal deployment should be happy (since the default is still
>>>>>>>> 1) and we wouldn't need to override it in Infinispan.
>>>>>>>>
>>>>>>>> On Tue, May 1, 2018 at 10:09 AM Tom Jenkinson <
>>>>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>>>>
>>>>>>>>> I am not sure - the default should be "1" for the bare metal case
>>>>>>>>> so the warning is reliably triggered but the default can be the pod name
>>>>>>>>> for OpenShift templates that only allow a single instance of the
>>>>>>>>> application server - does that help?
>>>>>>>>>
>>>>>>>>> The file you looked to want to edit is shared by bare metal and
>>>>>>>>> other deployment environments so it would be confusing to set the default
>>>>>>>>> to jboss.node.name there IMO.
>>>>>>>>>
>>>>>>>>> On 1 May 2018 at 03:39, Sebastian Laskawiec <slaskawi at redhat.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Fair enough Tom. Thanks for explanation.
>>>>>>>>>>
>>>>>>>>>> One more request - would you guys be OK with me adding
>>>>>>>>>> a node-identifier="${jboss.node.name}" to the transaction
>>>>>>>>>> subsystem template [1]? This way we wouldn't need to copy it into
>>>>>>>>>> Infinispan (since we need to set it).
>>>>>>>>>>
>>>>>>>>>> [1] https://github.com/wildfly/wildfly/blob/master/
>>>>>>>>>> transactions/src/main/resources/subsystem-templates/
>>>>>>>>>> transactions.xml#L6
>>>>>>>>>>
>>>>>>>>>> On Wed, Apr 18, 2018 at 3:37 PM Tom Jenkinson <
>>>>>>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 18 April 2018 at 14:07, Sebastian Laskawiec <
>>>>>>>>>>> slaskawi at redhat.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hey Tom,
>>>>>>>>>>>>
>>>>>>>>>>>> Comments inlined.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Apr 17, 2018 at 4:37 PM Tom Jenkinson <
>>>>>>>>>>>> tom.jenkinson at redhat.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 16 April 2018 at 09:31, <> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Adding +WildFly Dev <wildfly-dev at lists.jboss.org> to the
>>>>>>>>>>>>>> loop
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for the explanation Rado.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> TL;DR: A while ago Sanne pointed out that we do not set
>>>>>>>>>>>>>> `node-identifier`
>>>>>>>>>>>>>> in transaction subsystem by default. The default value for the
>>>>>>>>>>>>>> `node-identifier` attribute it `1`. Not setting this
>>>>>>>>>>>>>> attribute might cause
>>>>>>>>>>>>>> problems in transaction recovery. Perhaps we could follow
>>>>>>>>>>>>>> Rado's idea and
>>>>>>>>>>>>>> set it to node name by default?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Indeed - it would cause serious data integrity problems if a
>>>>>>>>>>>>> non-unique node-identifier is used.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Some more comments inlined.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Sebastian
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Apr 13, 2018 at 7:07 PM Radoslav Husar <rhusar at
>>>>>>>>>>>>>> redhat.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> > Hi Sebastian,
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > On Wed, Apr 11, 2018 at 2:31 PM, Sebastian Laskawiec
>>>>>>>>>>>>>> > <slaskawi at redhat.com> wrote:
>>>>>>>>>>>>>> > > Hey Rado, Paul,
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > > I started looking into this issue and it turned out that
>>>>>>>>>>>>>> WF subsystem
>>>>>>>>>>>>>> > > template doesn't provide `node-identifier` attribute [1].
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > I assume you mean that the default WildFly server profiles
>>>>>>>>>>>>>> do not
>>>>>>>>>>>>>>
>>>>>>>>>>>>> > explicitly define the attribute. Right ? thus the value
>>>>>>>>>>>>>> defaults in
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> > the model to "1"
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > https://github.com/wildfly/wildfly/blob/master/
>>>>>>>>>>>>>> transactions/src/main/java/org/jboss/as/txn/subsystem/
>>>>>>>>>>>>>> TransactionSubsystemRootResourceDefinition.java#L97
>>>>>>>>>>>>>> > which sole intention seems to be to log a warning on boot
>>>>>>>>>>>>>> if the value
>>>>>>>>>>>>>> > is unchanged.
>>>>>>>>>>>>>> > Why they decided on a constant that will be inherently not
>>>>>>>>>>>>>> unique as
>>>>>>>>>>>>>> > opposed to defaulting to the node name (which we already
>>>>>>>>>>>>>> require to be
>>>>>>>>>>>>>> > unique) as clustering node name or undertow instance-id
>>>>>>>>>>>>>> does, is
>>>>>>>>>>>>>> > unclear to me.
>>>>>>>>>>>>>> > Some context is on https://issues.jboss.org/
>>>>>>>>>>>>>> browse/WFLY-1119.
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In OpenShift environment we could set it to `hostname`. This
>>>>>>>>>>>>>> is guaranteed
>>>>>>>>>>>>>> to be unique in whole OpenShift cluster.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We do this too in EAP images.
>>>>>>>>>>>>> To Rado's point, the default is "1" so we can print the
>>>>>>>>>>>>> warning to alert people they are misconfigured - it seems to be working :)
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> This is the point. From my understanding, if we set it to node
>>>>>>>>>>>> name (instead of "1"), we could make it always work correctly. We could
>>>>>>>>>>>> even remove the code that emits the warning (since the node name needs to
>>>>>>>>>>>> be unique).
>>>>>>>>>>>>
>>>>>>>>>>>> To sum it up - if we decided to proceed this way, there would
>>>>>>>>>>>> be no requirement of setting the node-identifier at all.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> For OpenShift you are right there is no requirement for someone
>>>>>>>>>>> to change the node-identifier from the podname and so that is why EAP
>>>>>>>>>>> images do that.
>>>>>>>>>>>
>>>>>>>>>>> For bare-metal it is different as there can be two servers on
>>>>>>>>>>> the same machine so they were configured to use the hostname as they
>>>>>>>>>>> node-identifier then if they were also connected to the same resource
>>>>>>>>>>> managers or the same object store they would interfere with each other.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> > > I'm not sure if you guys are the right people to ask, but
>>>>>>>>>>>>>> is it safe to
>>>>>>>>>>>>>> > > leave it set to default? Or shall I override our
>>>>>>>>>>>>>> Infinispan templates and
>>>>>>>>>>>>>> > > add this parameter (as I mentioned before, in OpenShift
>>>>>>>>>>>>>> this I wanted to
>>>>>>>>>>>>>> > set
>>>>>>>>>>>>>> > > it as Pod name trimmed to the last 23 chars since this is
>>>>>>>>>>>>>> the limit).
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Putting a response to this in line - I am not certain who
>>>>>>>>>>>>> originally proposed this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You must use a globally unique node-identifier. If you are
>>>>>>>>>>>>> certain the last 23 characters guarantee that it would be valid - if there
>>>>>>>>>>>>> is a chance they are not unique it is not valid to trim.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> If that's not an issue, again, we could use the same limit as
>>>>>>>>>>>> we have for node name.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> > It is not safe to leave it set to "1" as that results in
>>>>>>>>>>>>>> inconsistent
>>>>>>>>>>>>>> > processing of transaction recovery.
>>>>>>>>>>>>>> > IIUC we already set it to the node name for both EAP and JDG
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/
>>>>>>>>>>>>>> master/os-eap70-openshift/added/standalone-openshift.xml#L411
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > https://github.com/jboss-openshift/cct_module/blob/
>>>>>>>>>>>>>> master/os-jdg7-conffiles/added/clustered-openshift.xml#L282
>>>>>>>>>>>>>>
>>>>>>>>>>>>> > which in turn defaults to the pod name ? so which profiles
>>>>>>>>>>>>>> are we
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> > talking about here?
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Granted, we set it by default in CCT Modules. However in
>>>>>>>>>>>>>> Infinispan we just
>>>>>>>>>>>>>> grab provided transaction subsystem when rendering full
>>>>>>>>>>>>>> configuration from
>>>>>>>>>>>>>> featurepacks:
>>>>>>>>>>>>>> https://github.com/infinispan/infinispan/blob/master/server/
>>>>>>>>>>>>>> integration/feature-pack/src/main/resources/configuration/
>>>>>>>>>>>>>> standalone/subsystems-cloud.xml#L19
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The default configuration XML doesn't contain the
>>>>>>>>>>>>>> `node-identifier`
>>>>>>>>>>>>>> attribute. I can add it manually in the cloud.xml but I
>>>>>>>>>>>>>> believe the right
>>>>>>>>>>>>>> approach is to modify the transaction subsystem.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> > Rado
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> > > Thanks,
>>>>>>>>>>>>>> > > Seb
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > > [1] usually set to node-identifier="${jboss.node.name}"
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>> > >
>>>>>>>>>>>>>>
>>>>>>>>>>>>> > > On Mon, Apr 9, 2018 at 10:39 AM Sanne Grinovero <sanne at
>>>>>>>>>>>>>> infinispan.org>
>>>>>>>>>>>>>> > > wrote:
>>>>>>>>>>>>>> > >>
>>>>>>>>>>>>>> > >> On 9 April 2018 at 09:26, Sebastian Laskawiec <slaskawi
>>>>>>>>>>>>>> at redhat.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>> > >> > Thanks for looking into it Sanne. Of course, we should
>>>>>>>>>>>>>> add it (it can
>>>>>>>>>>>>>> > be
>>>>>>>>>>>>>> > >> > set
>>>>>>>>>>>>>> > >> > to the same name as hostname since those are unique in
>>>>>>>>>>>>>> Kubernetes).
>>>>>>>>>>>>>> > >> >
>>>>>>>>>>>>>> > >> > Created https://issues.jboss.org/browse/ISPN-9051 for
>>>>>>>>>>>>>> it.
>>>>>>>>>>>>>> > >> >
>>>>>>>>>>>>>> > >> > Thanks again!
>>>>>>>>>>>>>> > >> > Seb
>>>>>>>>>>>>>> > >>
>>>>>>>>>>>>>> > >> Thanks Sebastian!
>>>>>>>>>>>>>> > >>
>>>>>>>>>>>>>> > >> >
>>>>>>>>>>>>>>
>>>>>>>>>>>>> > >> > On Fri, Apr 6, 2018 at 8:53 PM Sanne Grinovero <sanne
>>>>>>>>>>>>>> at infinispan.org>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> > >> > wrote:
>>>>>>>>>>>>>> > >> >>
>>>>>>>>>>>>>> > >> >> Hi all,
>>>>>>>>>>>>>> > >> >>
>>>>>>>>>>>>>> > >> >> I've started to use the Infinispan Openshift Template
>>>>>>>>>>>>>> and was
>>>>>>>>>>>>>> > browsing
>>>>>>>>>>>>>> > >> >> through the errors and warnings this produces.
>>>>>>>>>>>>>> > >> >>
>>>>>>>>>>>>>> > >> >> In particular I noticed "WFLYTX0013: Node identifier
>>>>>>>>>>>>>> property is set
>>>>>>>>>>>>>> > >> >> to the default value. Please make sure it is unique."
>>>>>>>>>>>>>> being produced
>>>>>>>>>>>>>> > >> >> by the transaction system.
>>>>>>>>>>>>>> > >> >>
>>>>>>>>>>>>>> > >> >> The node id is usually not needed for developer's
>>>>>>>>>>>>>> convenience and
>>>>>>>>>>>>>> > >> >> assuming there's a single node in "dev mode", yet
>>>>>>>>>>>>>> clearly the
>>>>>>>>>>>>>> > >> >> Infinispan template is meant to work with multiple
>>>>>>>>>>>>>> nodes running so
>>>>>>>>>>>>>> > >> >> this warning seems concerning.
>>>>>>>>>>>>>> > >> >>
>>>>>>>>>>>>>> > >> >> I'm not sure what the impact is on the transaction
>>>>>>>>>>>>>> manager so I asked
>>>>>>>>>>>>>> > >> >> on the Narayana forums; Tom pointed me to some
>>>>>>>>>>>>>> thourough design
>>>>>>>>>>>>>> > >> >> documents and also suggested the EAP image does set
>>>>>>>>>>>>>> the node
>>>>>>>>>>>>>> > >> >> identifier:
>>>>>>>>>>>>>> > >> >>  - https://developer.jboss.org/message/981702#981702
>>>>>>>>>>>>>> > >> >>
>>>>>>>>>>>>>> > >> >> WDYT? we probably want the Infinispan template to set
>>>>>>>>>>>>>> this as well,
>>>>>>>>>>>>>> > or
>>>>>>>>>>>>>> > >> >> silence the warning?
>>>>>>>>>>>>>> > >> >>
>>>>>>>>>>>>>> > >> >> Thanks,
>>>>>>>>>>>>>> > >> >> Sanne
>>>>>>>>>>>>>> > >> >> _______________________________________________
>>>>>>>>>>>>>> > >> >> infinispan-dev mailing list
>>>>>>>>>>>>>>
>>>>>>>>>>>>> > >> >> infinispan-dev at lists.jboss.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> > >> >> https://lists.jboss.org/mailman/listinfo/infinispan-
>>>>>>>>>>>>>> dev
>>>>>>>>>>>>>> > >> >
>>>>>>>>>>>>>> > >> >
>>>>>>>>>>>>>> > >> > _______________________________________________
>>>>>>>>>>>>>> > >> > infinispan-dev mailing list
>>>>>>>>>>>>>>
>>>>>>>>>>>>> > >> > infinispan-dev at lists.jboss.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> > >> > https://lists.jboss.org/mailman/listinfo/infinispan-
>>>>>>>>>>>>>> dev
>>>>>>>>>>>>>> > >> _______________________________________________
>>>>>>>>>>>>>> > >> infinispan-dev mailing list
>>>>>>>>>>>>>> > >> infinispan-dev at lists.jboss.org
>>>>>>>>>>>>>> > >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> -------------- next part --------------
>>>>>>>>>>>>>> An HTML attachment was scrubbed...
>>>>>>>>>>>>>> URL: http://lists.jboss.org/pipermail/wildfly-dev/
>>>>>>>>>>>>>> attachments/20180416/65962cf1/attachment-0001.html
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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/20180510/d6ca1fba/attachment-0001.html 

From kkhan at redhat.com  Thu May 10 12:13:05 2018
From: kkhan at redhat.com (Kabir Khan)
Date: Thu, 10 May 2018 17:13:05 +0100
Subject: [wildfly-dev] Proposal to revert component-matrix change
In-Reply-To: <a06540a6-d2be-054b-020b-8d65adce3a8f@redhat.com>
References: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
	<CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>
	<CANghgrQ5Tv9iprCBtbcP-XjF7S9pFSp1WztRHYYg7h1MYpyNhw@mail.gmail.com>
	<E44D4A57-C2A1-4B45-98AA-D90C56F82B24@redhat.com>
	<CAPhbRDYpJVgmwHC08PHtrGH+tUzzigu6zX6Ht-OXZqfymSNFVA@mail.gmail.com>
	<a06540a6-d2be-054b-020b-8d65adce3a8f@redhat.com>
Message-ID: <D36F0632-D162-4A49-980C-661AD2E4FA5F@redhat.com>

Here are the pull requests to move the version properties and dependency management back into the root pom.xml and getting rid of the component-matrix.

https://github.com/wildfly/wildfly-core/pull/3275
https://github.com/wildfly/wildfly/pull/11200

We need to release a Beta of core tomorrow so it can get in for the feature freeze. 

I am dabbling with generating the component-matrix contents by other means.



> On 9 May 2018, at 07:30, Petr Sakar <psakar at redhat.com> wrote:
> 
> Plugin is used by EAP maven repo build to generate eap-runtime bom eg [1] based on the feature packs dependency tree.
> 
> Relevant configuration is [2] 
> 
> Petr
> 
> [1] http://download-ipv4.eng.brq.redhat.com/brewroot/repos/jb-eap-7.2-maven-build/latest/maven/org/jboss/bom/eap-runtime-artifacts/7.2.0.CD12.CR2/eap-runtime-artifacts-7.2.0.CD12.CR2.pom
> 
> [2] http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-repository-testsuite.git/tree/repository-content/dependency-lists/eap-runtime-artifacts/pom.xml?h=eap-7.2.0.CD12#n105
> 
> On 05/08/2018 05:45 PM, Brian Stansberry wrote:
>> Hi Paul and Petr,
>> 
>> Do you know of any uses of this plugin we could learn from?
>> 
>> Best regards,
>> Brian
>> 
>> On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan at redhat.com> wrote:
>> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be used? I've not played with it
>> 
>> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd at redhat.com> wrote:
>> > 
>> > I've created https://issues.jboss.org/browse/WFLY-10330 and
>> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
>> > 
>> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene at redhat.com> wrote:
>> >> I agree. We can break the bom cycle a different way.
>> >> 
>> >>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd at redhat.com> wrote:
>> >>> 
>> >>> I propose we revert the component-matrix change.  This change is
>> >>> ostensibly to help in the creation of a BOM for the client libraries
>> >>> and other dependent projects; however, the cost has turned out to be
>> >>> somewhat higher than expected.
>> >>> 
>> >>> IntelliJ seems to be unable to cope with dependency changes in the
>> >>> project due to the use of import from the root POM.  This means that
>> >>> the entire project must be force-reimported from time to time to keep
>> >>> dependencies up to date, and forgetting to do so can lead to
>> >>> development issues and lost time.
>> >>> 
>> >>> Also, I've observed that Maven itself does not always correctly
>> >>> resolve versions anymore, when you're building from a submodule.  I
>> >>> don't really know why this is the case but I suspect that it's due to
>> >>> some algorithmic ambiguity when the dependency tree is not linear like
>> >>> it used to be.
>> >>> 
>> >>> I think that if we need to generate some BOM for use by external
>> >>> projects, it should be done as a separate step and artifact which
>> >>> acquires versions from the parent.  I believe we had it this way at
>> >>> one point, didn't we?
>> >>> 
>> >>> Anyway I think this change didn't work out, and we should undo it
>> >>> while it's still remotely possible.  WDYT?
>> >>> 
>> >>> --
>> >>> - DML
>> >>> _______________________________________________
>> >>> wildfly-dev mailing list
>> >>> wildfly-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> > 
>> > 
>> > 
>> > -- 
>> > - DML
>> > _______________________________________________
>> > wildfly-dev mailing list
>> > wildfly-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> 
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> 
>> 
>> 
>> -- 
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
> 



From darran.lofthouse at redhat.com  Thu May 10 12:28:53 2018
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Thu, 10 May 2018 16:28:53 +0000
Subject: [wildfly-dev] Proposal to revert component-matrix change
In-Reply-To: <D36F0632-D162-4A49-980C-661AD2E4FA5F@redhat.com>
References: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
	<CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>
	<CANghgrQ5Tv9iprCBtbcP-XjF7S9pFSp1WztRHYYg7h1MYpyNhw@mail.gmail.com>
	<E44D4A57-C2A1-4B45-98AA-D90C56F82B24@redhat.com>
	<CAPhbRDYpJVgmwHC08PHtrGH+tUzzigu6zX6Ht-OXZqfymSNFVA@mail.gmail.com>
	<a06540a6-d2be-054b-020b-8d65adce3a8f@redhat.com>
	<D36F0632-D162-4A49-980C-661AD2E4FA5F@redhat.com>
Message-ID: <CAMxVf4PEpJFA1ngfQETiYFC2eYCQ1wN9ynE3jvtg_CZi317sig@mail.gmail.com>

FYI I am planning a set of WildFly Elytron component upgrades tomorrow
morning.

Regards,
Darran Lofthouse.


On Thu, 10 May 2018 at 17:25 Kabir Khan <kkhan at redhat.com> wrote:

> Here are the pull requests to move the version properties and dependency
> management back into the root pom.xml and getting rid of the
> component-matrix.
>
> https://github.com/wildfly/wildfly-core/pull/3275
> https://github.com/wildfly/wildfly/pull/11200
>
> We need to release a Beta of core tomorrow so it can get in for the
> feature freeze.
>
> I am dabbling with generating the component-matrix contents by other means.
>
>
>
> > On 9 May 2018, at 07:30, Petr Sakar <psakar at redhat.com> wrote:
> >
> > Plugin is used by EAP maven repo build to generate eap-runtime bom eg
> [1] based on the feature packs dependency tree.
> >
> > Relevant configuration is [2]
> >
> > Petr
> >
> > [1]
> http://download-ipv4.eng.brq.redhat.com/brewroot/repos/jb-eap-7.2-maven-build/latest/maven/org/jboss/bom/eap-runtime-artifacts/7.2.0.CD12.CR2/eap-runtime-artifacts-7.2.0.CD12.CR2.pom
> >
> > [2]
> http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-repository-testsuite.git/tree/repository-content/dependency-lists/eap-runtime-artifacts/pom.xml?h=eap-7.2.0.CD12#n105
> >
> > On 05/08/2018 05:45 PM, Brian Stansberry wrote:
> >> Hi Paul and Petr,
> >>
> >> Do you know of any uses of this plugin we could learn from?
> >>
> >> Best regards,
> >> Brian
> >>
> >> On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan at redhat.com> wrote:
> >> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be used?
> I've not played with it
> >>
> >> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd at redhat.com> wrote:
> >> >
> >> > I've created https://issues.jboss.org/browse/WFLY-10330 and
> >> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
> >> >
> >> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene at redhat.com>
> wrote:
> >> >> I agree. We can break the bom cycle a different way.
> >> >>
> >> >>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd at redhat.com>
> wrote:
> >> >>>
> >> >>> I propose we revert the component-matrix change.  This change is
> >> >>> ostensibly to help in the creation of a BOM for the client libraries
> >> >>> and other dependent projects; however, the cost has turned out to be
> >> >>> somewhat higher than expected.
> >> >>>
> >> >>> IntelliJ seems to be unable to cope with dependency changes in the
> >> >>> project due to the use of import from the root POM.  This means that
> >> >>> the entire project must be force-reimported from time to time to
> keep
> >> >>> dependencies up to date, and forgetting to do so can lead to
> >> >>> development issues and lost time.
> >> >>>
> >> >>> Also, I've observed that Maven itself does not always correctly
> >> >>> resolve versions anymore, when you're building from a submodule.  I
> >> >>> don't really know why this is the case but I suspect that it's due
> to
> >> >>> some algorithmic ambiguity when the dependency tree is not linear
> like
> >> >>> it used to be.
> >> >>>
> >> >>> I think that if we need to generate some BOM for use by external
> >> >>> projects, it should be done as a separate step and artifact which
> >> >>> acquires versions from the parent.  I believe we had it this way at
> >> >>> one point, didn't we?
> >> >>>
> >> >>> Anyway I think this change didn't work out, and we should undo it
> >> >>> while it's still remotely possible.  WDYT?
> >> >>>
> >> >>> --
> >> >>> - DML
> >> >>> _______________________________________________
> >> >>> wildfly-dev mailing list
> >> >>> wildfly-dev at lists.jboss.org
> >> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> >
> >> >
> >> >
> >> > --
> >> > - DML
> >> > _______________________________________________
> >> > wildfly-dev mailing list
> >> > wildfly-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >>
> >>
> >> --
> >> 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/20180510/2fc79c58/attachment.html 

From darran.lofthouse at redhat.com  Thu May 10 12:34:05 2018
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Thu, 10 May 2018 16:34:05 +0000
Subject: [wildfly-dev] Proposal to revert component-matrix change
In-Reply-To: <CAMxVf4PEpJFA1ngfQETiYFC2eYCQ1wN9ynE3jvtg_CZi317sig@mail.gmail.com>
References: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
	<CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>
	<CANghgrQ5Tv9iprCBtbcP-XjF7S9pFSp1WztRHYYg7h1MYpyNhw@mail.gmail.com>
	<E44D4A57-C2A1-4B45-98AA-D90C56F82B24@redhat.com>
	<CAPhbRDYpJVgmwHC08PHtrGH+tUzzigu6zX6Ht-OXZqfymSNFVA@mail.gmail.com>
	<a06540a6-d2be-054b-020b-8d65adce3a8f@redhat.com>
	<D36F0632-D162-4A49-980C-661AD2E4FA5F@redhat.com>
	<CAMxVf4PEpJFA1ngfQETiYFC2eYCQ1wN9ynE3jvtg_CZi317sig@mail.gmail.com>
Message-ID: <CAMxVf4P5V0Y77-EU5WuVz8_HJ6e_j95reA263d3gegotFtn+4Q@mail.gmail.com>

Also this Blocker is dependent on a JBoss Modules upgrade that David is
currently working on - https://issues.jboss.org/browse/WFCORE-3799

On Thu, 10 May 2018 at 17:28 Darran Lofthouse <darran.lofthouse at redhat.com>
wrote:

> FYI I am planning a set of WildFly Elytron component upgrades tomorrow
> morning.
>
> Regards,
> Darran Lofthouse.
>
>
> On Thu, 10 May 2018 at 17:25 Kabir Khan <kkhan at redhat.com> wrote:
>
>> Here are the pull requests to move the version properties and dependency
>> management back into the root pom.xml and getting rid of the
>> component-matrix.
>>
>> https://github.com/wildfly/wildfly-core/pull/3275
>> https://github.com/wildfly/wildfly/pull/11200
>>
>> We need to release a Beta of core tomorrow so it can get in for the
>> feature freeze.
>>
>> I am dabbling with generating the component-matrix contents by other
>> means.
>>
>>
>>
>> > On 9 May 2018, at 07:30, Petr Sakar <psakar at redhat.com> wrote:
>> >
>> > Plugin is used by EAP maven repo build to generate eap-runtime bom eg
>> [1] based on the feature packs dependency tree.
>> >
>> > Relevant configuration is [2]
>> >
>> > Petr
>> >
>> > [1]
>> http://download-ipv4.eng.brq.redhat.com/brewroot/repos/jb-eap-7.2-maven-build/latest/maven/org/jboss/bom/eap-runtime-artifacts/7.2.0.CD12.CR2/eap-runtime-artifacts-7.2.0.CD12.CR2.pom
>> >
>> > [2]
>> http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-repository-testsuite.git/tree/repository-content/dependency-lists/eap-runtime-artifacts/pom.xml?h=eap-7.2.0.CD12#n105
>> >
>> > On 05/08/2018 05:45 PM, Brian Stansberry wrote:
>> >> Hi Paul and Petr,
>> >>
>> >> Do you know of any uses of this plugin we could learn from?
>> >>
>> >> Best regards,
>> >> Brian
>> >>
>> >> On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan at redhat.com> wrote:
>> >> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be
>> used? I've not played with it
>> >>
>> >> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd at redhat.com> wrote:
>> >> >
>> >> > I've created https://issues.jboss.org/browse/WFLY-10330 and
>> >> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
>> >> >
>> >> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <
>> jason.greene at redhat.com> wrote:
>> >> >> I agree. We can break the bom cycle a different way.
>> >> >>
>> >> >>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd at redhat.com>
>> wrote:
>> >> >>>
>> >> >>> I propose we revert the component-matrix change.  This change is
>> >> >>> ostensibly to help in the creation of a BOM for the client
>> libraries
>> >> >>> and other dependent projects; however, the cost has turned out to
>> be
>> >> >>> somewhat higher than expected.
>> >> >>>
>> >> >>> IntelliJ seems to be unable to cope with dependency changes in the
>> >> >>> project due to the use of import from the root POM.  This means
>> that
>> >> >>> the entire project must be force-reimported from time to time to
>> keep
>> >> >>> dependencies up to date, and forgetting to do so can lead to
>> >> >>> development issues and lost time.
>> >> >>>
>> >> >>> Also, I've observed that Maven itself does not always correctly
>> >> >>> resolve versions anymore, when you're building from a submodule.  I
>> >> >>> don't really know why this is the case but I suspect that it's due
>> to
>> >> >>> some algorithmic ambiguity when the dependency tree is not linear
>> like
>> >> >>> it used to be.
>> >> >>>
>> >> >>> I think that if we need to generate some BOM for use by external
>> >> >>> projects, it should be done as a separate step and artifact which
>> >> >>> acquires versions from the parent.  I believe we had it this way at
>> >> >>> one point, didn't we?
>> >> >>>
>> >> >>> Anyway I think this change didn't work out, and we should undo it
>> >> >>> while it's still remotely possible.  WDYT?
>> >> >>>
>> >> >>> --
>> >> >>> - DML
>> >> >>> _______________________________________________
>> >> >>> wildfly-dev mailing list
>> >> >>> wildfly-dev at lists.jboss.org
>> >> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > - DML
>> >> > _______________________________________________
>> >> > wildfly-dev mailing list
>> >> > wildfly-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>> >> wildfly-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>
>> >>
>> >>
>> >> --
>> >> 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/20180510/40481281/attachment-0001.html 

From kkhan at redhat.com  Thu May 10 12:36:17 2018
From: kkhan at redhat.com (Kabir Khan)
Date: Thu, 10 May 2018 17:36:17 +0100
Subject: [wildfly-dev] Proposal to revert component-matrix change
In-Reply-To: <CAMxVf4PEpJFA1ngfQETiYFC2eYCQ1wN9ynE3jvtg_CZi317sig@mail.gmail.com>
References: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
	<CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>
	<CANghgrQ5Tv9iprCBtbcP-XjF7S9pFSp1WztRHYYg7h1MYpyNhw@mail.gmail.com>
	<E44D4A57-C2A1-4B45-98AA-D90C56F82B24@redhat.com>
	<CAPhbRDYpJVgmwHC08PHtrGH+tUzzigu6zX6Ht-OXZqfymSNFVA@mail.gmail.com>
	<a06540a6-d2be-054b-020b-8d65adce3a8f@redhat.com>
	<D36F0632-D162-4A49-980C-661AD2E4FA5F@redhat.com>
	<CAMxVf4PEpJFA1ngfQETiYFC2eYCQ1wN9ynE3jvtg_CZi317sig@mail.gmail.com>
Message-ID: <4175048A-CF6E-4FC8-AD22-50E89AF764B7@redhat.com>

We aim to have them merged once tests complete.

> On 10 May 2018, at 17:28, Darran Lofthouse <darran.lofthouse at redhat.com> wrote:
> 
> FYI I am planning a set of WildFly Elytron component upgrades tomorrow morning.
> 
> Regards,
> Darran Lofthouse.
> 
> 
> On Thu, 10 May 2018 at 17:25 Kabir Khan <kkhan at redhat.com> wrote:
> Here are the pull requests to move the version properties and dependency management back into the root pom.xml and getting rid of the component-matrix.
> 
> https://github.com/wildfly/wildfly-core/pull/3275
> https://github.com/wildfly/wildfly/pull/11200
> 
> We need to release a Beta of core tomorrow so it can get in for the feature freeze. 
> 
> I am dabbling with generating the component-matrix contents by other means.
> 
> 
> 
> > On 9 May 2018, at 07:30, Petr Sakar <psakar at redhat.com> wrote:
> > 
> > Plugin is used by EAP maven repo build to generate eap-runtime bom eg [1] based on the feature packs dependency tree.
> > 
> > Relevant configuration is [2] 
> > 
> > Petr
> > 
> > [1] http://download-ipv4.eng.brq.redhat.com/brewroot/repos/jb-eap-7.2-maven-build/latest/maven/org/jboss/bom/eap-runtime-artifacts/7.2.0.CD12.CR2/eap-runtime-artifacts-7.2.0.CD12.CR2.pom
> > 
> > [2] http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-repository-testsuite.git/tree/repository-content/dependency-lists/eap-runtime-artifacts/pom.xml?h=eap-7.2.0.CD12#n105
> > 
> > On 05/08/2018 05:45 PM, Brian Stansberry wrote:
> >> Hi Paul and Petr,
> >> 
> >> Do you know of any uses of this plugin we could learn from?
> >> 
> >> Best regards,
> >> Brian
> >> 
> >> On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan at redhat.com> wrote:
> >> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be used? I've not played with it
> >> 
> >> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd at redhat.com> wrote:
> >> > 
> >> > I've created https://issues.jboss.org/browse/WFLY-10330 and
> >> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
> >> > 
> >> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene at redhat.com> wrote:
> >> >> I agree. We can break the bom cycle a different way.
> >> >> 
> >> >>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd at redhat.com> wrote:
> >> >>> 
> >> >>> I propose we revert the component-matrix change.  This change is
> >> >>> ostensibly to help in the creation of a BOM for the client libraries
> >> >>> and other dependent projects; however, the cost has turned out to be
> >> >>> somewhat higher than expected.
> >> >>> 
> >> >>> IntelliJ seems to be unable to cope with dependency changes in the
> >> >>> project due to the use of import from the root POM.  This means that
> >> >>> the entire project must be force-reimported from time to time to keep
> >> >>> dependencies up to date, and forgetting to do so can lead to
> >> >>> development issues and lost time.
> >> >>> 
> >> >>> Also, I've observed that Maven itself does not always correctly
> >> >>> resolve versions anymore, when you're building from a submodule.  I
> >> >>> don't really know why this is the case but I suspect that it's due to
> >> >>> some algorithmic ambiguity when the dependency tree is not linear like
> >> >>> it used to be.
> >> >>> 
> >> >>> I think that if we need to generate some BOM for use by external
> >> >>> projects, it should be done as a separate step and artifact which
> >> >>> acquires versions from the parent.  I believe we had it this way at
> >> >>> one point, didn't we?
> >> >>> 
> >> >>> Anyway I think this change didn't work out, and we should undo it
> >> >>> while it's still remotely possible.  WDYT?
> >> >>> 
> >> >>> --
> >> >>> - DML
> >> >>> _______________________________________________
> >> >>> wildfly-dev mailing list
> >> >>> wildfly-dev at lists.jboss.org
> >> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> > 
> >> > 
> >> > 
> >> > -- 
> >> > - DML
> >> > _______________________________________________
> >> > wildfly-dev mailing list
> >> > wildfly-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> 
> >> 
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> 
> >> 
> >> 
> >> -- 
> >> 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 tomaz.cerar at gmail.com  Thu May 10 16:19:35 2018
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 10 May 2018 22:19:35 +0200
Subject: [wildfly-dev] Proposal to revert component-matrix change
In-Reply-To: <D36F0632-D162-4A49-980C-661AD2E4FA5F@redhat.com>
References: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
	<CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>
	<CANghgrQ5Tv9iprCBtbcP-XjF7S9pFSp1WztRHYYg7h1MYpyNhw@mail.gmail.com>
	<E44D4A57-C2A1-4B45-98AA-D90C56F82B24@redhat.com>
	<CAPhbRDYpJVgmwHC08PHtrGH+tUzzigu6zX6Ht-OXZqfymSNFVA@mail.gmail.com>
	<a06540a6-d2be-054b-020b-8d65adce3a8f@redhat.com>
	<D36F0632-D162-4A49-980C-661AD2E4FA5F@redhat.com>
Message-ID: <CAMquZP7ah78-p=R=r3Ff7VhDK0ynzTHeChQrA9i0=1HH=w-pyQ@mail.gmail.com>

> I am dabbling with generating the component-matrix contents by other
means.

If component-matrix (or whatever is decided to be called) is not available
/ done / released
as part of server release itself or it is lacking any of the components or
is out of sync on release it is useless!

Main driver for having it like this was to provide users complete component
version matrix
so they are able to import it to their IDE to aid with sources when they
are debugging application running on server.

Currently only somewhat similar thing we have is "wildfly-parent" which is
much more than just component matrix.

So just keep in mind what the user requirements / desires are.

--
tomaz

On Thu, May 10, 2018 at 6:13 PM, Kabir Khan <kkhan at redhat.com> wrote:

> Here are the pull requests to move the version properties and dependency
> management back into the root pom.xml and getting rid of the
> component-matrix.
>
> https://github.com/wildfly/wildfly-core/pull/3275
> https://github.com/wildfly/wildfly/pull/11200
>
> We need to release a Beta of core tomorrow so it can get in for the
> feature freeze.
>
> I am dabbling with generating the component-matrix contents by other means.
>
>
>
> > On 9 May 2018, at 07:30, Petr Sakar <psakar at redhat.com> wrote:
> >
> > Plugin is used by EAP maven repo build to generate eap-runtime bom eg
> [1] based on the feature packs dependency tree.
> >
> > Relevant configuration is [2]
> >
> > Petr
> >
> > [1] http://download-ipv4.eng.brq.redhat.com/brewroot/repos/jb-
> eap-7.2-maven-build/latest/maven/org/jboss/bom/eap-
> runtime-artifacts/7.2.0.CD12.CR2/eap-runtime-artifacts-7.2.0.CD12.CR2.pom
> >
> > [2] http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-
> repository-testsuite.git/tree/repository-content/dependency-
> lists/eap-runtime-artifacts/pom.xml?h=eap-7.2.0.CD12#n105
> >
> > On 05/08/2018 05:45 PM, Brian Stansberry wrote:
> >> Hi Paul and Petr,
> >>
> >> Do you know of any uses of this plugin we could learn from?
> >>
> >> Best regards,
> >> Brian
> >>
> >> On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan at redhat.com> wrote:
> >> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be used?
> I've not played with it
> >>
> >> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd at redhat.com> wrote:
> >> >
> >> > I've created https://issues.jboss.org/browse/WFLY-10330 and
> >> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
> >> >
> >> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <jason.greene at redhat.com>
> wrote:
> >> >> I agree. We can break the bom cycle a different way.
> >> >>
> >> >>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd at redhat.com>
> wrote:
> >> >>>
> >> >>> I propose we revert the component-matrix change.  This change is
> >> >>> ostensibly to help in the creation of a BOM for the client libraries
> >> >>> and other dependent projects; however, the cost has turned out to be
> >> >>> somewhat higher than expected.
> >> >>>
> >> >>> IntelliJ seems to be unable to cope with dependency changes in the
> >> >>> project due to the use of import from the root POM.  This means that
> >> >>> the entire project must be force-reimported from time to time to
> keep
> >> >>> dependencies up to date, and forgetting to do so can lead to
> >> >>> development issues and lost time.
> >> >>>
> >> >>> Also, I've observed that Maven itself does not always correctly
> >> >>> resolve versions anymore, when you're building from a submodule.  I
> >> >>> don't really know why this is the case but I suspect that it's due
> to
> >> >>> some algorithmic ambiguity when the dependency tree is not linear
> like
> >> >>> it used to be.
> >> >>>
> >> >>> I think that if we need to generate some BOM for use by external
> >> >>> projects, it should be done as a separate step and artifact which
> >> >>> acquires versions from the parent.  I believe we had it this way at
> >> >>> one point, didn't we?
> >> >>>
> >> >>> Anyway I think this change didn't work out, and we should undo it
> >> >>> while it's still remotely possible.  WDYT?
> >> >>>
> >> >>> --
> >> >>> - DML
> >> >>> _______________________________________________
> >> >>> wildfly-dev mailing list
> >> >>> wildfly-dev at lists.jboss.org
> >> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> >
> >> >
> >> >
> >> > --
> >> > - DML
> >> > _______________________________________________
> >> > wildfly-dev mailing list
> >> > wildfly-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >>
> >>
> >> --
> >> 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/20180510/db1b5d74/attachment.html 

From brian.stansberry at redhat.com  Thu May 10 17:51:50 2018
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 10 May 2018 16:51:50 -0500
Subject: [wildfly-dev] Proposal to revert component-matrix change
In-Reply-To: <CAMquZP7ah78-p=R=r3Ff7VhDK0ynzTHeChQrA9i0=1HH=w-pyQ@mail.gmail.com>
References: <CANghgrQ-Wxn4H_cJ+qfjABAypuh2Tq7uX6Gx=PvZwFpU=4D8OQ@mail.gmail.com>
	<CAJMo4+cPUf+Ho4SXA0x8jEXo0ea=13ypNOHZSWrOf7GFEGGWjw@mail.gmail.com>
	<CANghgrQ5Tv9iprCBtbcP-XjF7S9pFSp1WztRHYYg7h1MYpyNhw@mail.gmail.com>
	<E44D4A57-C2A1-4B45-98AA-D90C56F82B24@redhat.com>
	<CAPhbRDYpJVgmwHC08PHtrGH+tUzzigu6zX6Ht-OXZqfymSNFVA@mail.gmail.com>
	<a06540a6-d2be-054b-020b-8d65adce3a8f@redhat.com>
	<D36F0632-D162-4A49-980C-661AD2E4FA5F@redhat.com>
	<CAMquZP7ah78-p=R=r3Ff7VhDK0ynzTHeChQrA9i0=1HH=w-pyQ@mail.gmail.com>
Message-ID: <CAPhbRDaKCp-BY0sn2LbY+rNXBFB1zaEvMG0iSdkFWJOG5pAEUQ@mail.gmail.com>

On Thu, May 10, 2018 at 3:19 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

> > I am dabbling with generating the component-matrix contents by other
> means.
>
> If component-matrix (or whatever is decided to be called) is not available
> / done / released
> as part of server release itself
>

The idea is to generate it as part of the build itself.

or it is lacking any of the components or is out of sync on release it is
> useless!
>
> Main driver for having it like this was to provide users complete
> component version matrix
> so they are able to import it to their IDE to aid with sources when they
> are debugging application running on server.
>
> Currently only somewhat similar thing we have is "wildfly-parent" which is
> much more than just component matrix.
>
> So just keep in mind what the user requirements / desires are.
>
> --
> tomaz
>
> On Thu, May 10, 2018 at 6:13 PM, Kabir Khan <kkhan at redhat.com> wrote:
>
>> Here are the pull requests to move the version properties and dependency
>> management back into the root pom.xml and getting rid of the
>> component-matrix.
>>
>> https://github.com/wildfly/wildfly-core/pull/3275
>> https://github.com/wildfly/wildfly/pull/11200
>>
>> We need to release a Beta of core tomorrow so it can get in for the
>> feature freeze.
>>
>> I am dabbling with generating the component-matrix contents by other
>> means.
>>
>>
>>
>> > On 9 May 2018, at 07:30, Petr Sakar <psakar at redhat.com> wrote:
>> >
>> > Plugin is used by EAP maven repo build to generate eap-runtime bom eg
>> [1] based on the feature packs dependency tree.
>> >
>> > Relevant configuration is [2]
>> >
>> > Petr
>> >
>> > [1] http://download-ipv4.eng.brq.redhat.com/brewroot/repos/jb-ea
>> p-7.2-maven-build/latest/maven/org/jboss/bom/eap-runtime-
>> artifacts/7.2.0.CD12.CR2/eap-runtime-artifacts-7.2.0.CD12.CR2.pom
>> >
>> > [2] http://git.app.eng.bos.redhat.com/git/jboss-eap/maven-reposi
>> tory-testsuite.git/tree/repository-content/dependency-lists/
>> eap-runtime-artifacts/pom.xml?h=eap-7.2.0.CD12#n105
>> >
>> > On 05/08/2018 05:45 PM, Brian Stansberry wrote:
>> >> Hi Paul and Petr,
>> >>
>> >> Do you know of any uses of this plugin we could learn from?
>> >>
>> >> Best regards,
>> >> Brian
>> >>
>> >> On Sat, May 5, 2018 at 4:25 AM, Kabir Khan <kkhan at redhat.com> wrote:
>> >> Perhaps https://github.com/jboss/bom-builder-maven-plugin can be
>> used? I've not played with it
>> >>
>> >> > On 4 May 2018, at 22:11, David Lloyd <david.lloyd at redhat.com> wrote:
>> >> >
>> >> > I've created https://issues.jboss.org/browse/WFLY-10330 and
>> >> > https://issues.jboss.org/browse/WFCORE-3803 to track this.
>> >> >
>> >> > On Fri, May 4, 2018 at 4:04 PM, Jason Greene <
>> jason.greene at redhat.com> wrote:
>> >> >> I agree. We can break the bom cycle a different way.
>> >> >>
>> >> >>> On May 4, 2018, at 3:53 PM, David Lloyd <david.lloyd at redhat.com>
>> wrote:
>> >> >>>
>> >> >>> I propose we revert the component-matrix change.  This change is
>> >> >>> ostensibly to help in the creation of a BOM for the client
>> libraries
>> >> >>> and other dependent projects; however, the cost has turned out to
>> be
>> >> >>> somewhat higher than expected.
>> >> >>>
>> >> >>> IntelliJ seems to be unable to cope with dependency changes in the
>> >> >>> project due to the use of import from the root POM.  This means
>> that
>> >> >>> the entire project must be force-reimported from time to time to
>> keep
>> >> >>> dependencies up to date, and forgetting to do so can lead to
>> >> >>> development issues and lost time.
>> >> >>>
>> >> >>> Also, I've observed that Maven itself does not always correctly
>> >> >>> resolve versions anymore, when you're building from a submodule.  I
>> >> >>> don't really know why this is the case but I suspect that it's due
>> to
>> >> >>> some algorithmic ambiguity when the dependency tree is not linear
>> like
>> >> >>> it used to be.
>> >> >>>
>> >> >>> I think that if we need to generate some BOM for use by external
>> >> >>> projects, it should be done as a separate step and artifact which
>> >> >>> acquires versions from the parent.  I believe we had it this way at
>> >> >>> one point, didn't we?
>> >> >>>
>> >> >>> Anyway I think this change didn't work out, and we should undo it
>> >> >>> while it's still remotely possible.  WDYT?
>> >> >>>
>> >> >>> --
>> >> >>> - DML
>> >> >>> _______________________________________________
>> >> >>> wildfly-dev mailing list
>> >> >>> wildfly-dev at lists.jboss.org
>> >> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > - DML
>> >> > _______________________________________________
>> >> > wildfly-dev mailing list
>> >> > wildfly-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>
>> >>
>> >> _______________________________________________
>> >> wildfly-dev mailing list
>> >> wildfly-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> >>
>> >>
>> >>
>> >> --
>> >> 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
>>
>
>
> _______________________________________________
> 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/20180510/0fa4b028/attachment-0001.html 

From jdenise at redhat.com  Fri May 11 14:07:19 2018
From: jdenise at redhat.com (Jean-Francois Denise)
Date: Fri, 11 May 2018 20:07:19 +0200
Subject: [wildfly-dev] galleon cli demo
Message-ID: <4fe7460a-5bec-b236-232d-2f594cd0aa93@redhat.com>

Hi,

yesterday during management team meeting I have presented some of the 
features (incubating...) that have been implemented in galleon cli 
command line tool. The recording[1] contains the demo (a "fine grained" 
provisioning of a web application), Q&A and Alexey demo of wildfly CLI 
scripts generation from the same galleon cli tool. In case you have time 
to watch the recording your feedbacks would be well appreciated.

Thank-you.

JF

[1] 
https://bluejeans.com/playback/s/URuah7Xv77AvKmDhxz0kSuI6eLxXCDshXdJFG64qDR8X7xHefQeFjQ3bKKXoStof



From brian.stansberry at redhat.com  Fri May 11 16:35:03 2018
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Fri, 11 May 2018 15:35:03 -0500
Subject: [wildfly-dev] galleon cli demo
In-Reply-To: <4fe7460a-5bec-b236-232d-2f594cd0aa93@redhat.com>
References: <4fe7460a-5bec-b236-232d-2f594cd0aa93@redhat.com>
Message-ID: <CAPhbRDYSoK9f0hgP1LN5QAO2DCZjJXzYR7L47cHMheEUgHYVYg@mail.gmail.com>

Thanks, Jean-Francois for doing that. That was interesting to see and it
was a good discussion.

The tooling is making rapid progress! It's going to be an interesting
summer.

On Fri, May 11, 2018 at 1:07 PM, Jean-Francois Denise <jdenise at redhat.com>
wrote:

> Hi,
>
> yesterday during management team meeting I have presented some of the
> features (incubating...) that have been implemented in galleon cli
> command line tool. The recording[1] contains the demo (a "fine grained"
> provisioning of a web application), Q&A and Alexey demo of wildfly CLI
> scripts generation from the same galleon cli tool. In case you have time
> to watch the recording your feedbacks would be well appreciated.
>
> Thank-you.
>
> JF
>
> [1]
> https://bluejeans.com/playback/s/URuah7Xv77AvKmDhxz0kSuI6eLxXCD
> shXdJFG64qDR8X7xHefQeFjQ3bKKXoStof
>
>
> _______________________________________________
> 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/20180511/7beff3ef/attachment.html 

From mstefank at redhat.com  Tue May 15 05:57:20 2018
From: mstefank at redhat.com (Martin Stefanko)
Date: Tue, 15 May 2018 11:57:20 +0200
Subject: [wildfly-dev] PR template check
Message-ID: <CAEEDSKVXkqvonbvyc9QT-sA2gOTP4wxR5GaeOqGxP2UFKa_gYw@mail.gmail.com>

Hi all,

I've created a tool [1] that validates the PR format. For now it checks the
title and the description for the required information configured by regex
expressions. It runs on my OS online and is configured in [2] on the master
branch.

The tool uses GH webhooks which needs to be set up in the targeting
repository and it requires the respective OAuth token, for now configured
through the OS secret.

This is the basic functionality, I can add more checks later (e.g., link
validity, number of commits). Any feedback is welcome.

[1] https://github.com/xstefank/tyr
[2] https://github.com/xstefank/test-repo
?
 tyr.mp4
<https://drive.google.com/a/redhat.com/file/d/1QCeBSoviD2Xj9ycPjrH8cjwlbwEHcCji/view?usp=drive_web>
?

Martin Stefanko

Software Engineer
JBoss Sustaining Engineering Team
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180515/2e941e56/attachment.html 

From sanne at hibernate.org  Tue May 15 06:32:27 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 15 May 2018 11:32:27 +0100
Subject: [wildfly-dev] Docs & examples to update Hibernate ORM via the
 (existing) provisioning tool
Message-ID: <CAFm4XO1RV01pi5JpnRN6dDS-pFXkE_HPwyz=Wgp1qoqQoH0isA@mail.gmail.com>

Hi all,

while I haven't looked at Galleon yet, we now have guidelines for
Hibernate users wishing to run the very latest Hibernate ORM (Search,
OGM) on WildFly:

 - https://docs.jboss.org/hibernate/orm/5.3/topical/html_single/wildfly/Wildfly.html

Some personal thoughts:
 - the feature packs are awesome
 - having slots (and multiple conflicting versions / layers) is
extremely useful and an advantage over Jigsaw which I hope we'll keep
having
 - it's striking how much Gradle is easier, faster, and more powerful
than Maven: see my examples as I've included fully runnable Gradle
build scripts.

Please don't neglect Gradle's needs and users as it's thriwing in
other communities, while it feels a like second class citizen in the
WildFly ecosystem.
I've done my part by creating the Gradle WildFly Provisioning plugin
mentioned in the docs but I'd like to see more of such things :)


# Many feature packs!

We created lots of feature packs in the Hibernate community; on top of
the Hibernate ORM pack you can find:

Hibernate Search has been split in 5 fine-grained packs:
 - https://docs.jboss.org/hibernate/search/5.10/reference/en-US/html_single/#hibernatesearch-jboss-modules-feature-packs

We also separated into independently released packs some of the
dependencies which people might want to use w/o necessarily pulling in
Hibernate bits:

Elasticsearch client drivers:
 - https://github.com/hibernate/elasticsearch-client-jbossmodules

Extensions to the Elasticsearch integration which are specific for AWS
security requirements:
- https://github.com/hibernate/aws-v4-signer-java-jbossmodules

GSON packaged for WildFly:
 - https://github.com/hibernate/gson-jbossmodules

Lucene, packaged for WildFly:
  - https://github.com/hibernate/lucene-jbossmodules

Hibernate OGM is releasing soon as well and will double this list: one
pack for the main artifact plus one for each NoSQL technology's driver
and dialects.

# What's next?

   Many of the above backs just require wildfly-core, yet Hibernate
ORM requires the "full server" as we need various subsystems such as
JTA and Datasources.

   I hope you'll all make these fine-grained so that in the near
future the Hibernate ORM feature pack could declare a smaller
dependency set?

   Also I'm looking forward to suggestions on what we need to do to
get these e.g. in some kind of catalogue / repository - I'm
understanding Galleon would be able to help with discovery?

Thanks,
Sanne

From rsvoboda at redhat.com  Tue May 15 07:28:51 2018
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Tue, 15 May 2018 13:28:51 +0200
Subject: [wildfly-dev] Generate WildFly BOMs as part of WildFly build
Message-ID: <CACa2xU9SpPDgeE2mz-nHVcAOxoG39n35yC36x8Ym9ubNSjbbaw@mail.gmail.com>

Hi team.

WildFly and WildFly core generate component-matrix as part of the build now.
  https://issues.jboss.org/browse/WFLY-10365

We should also consider automated propagation of current WildFly master
component versions into WildFly BOMs - https://github.com/wildfly/boms. I'm
especially interested in https://github.com/wildfly/boms/tree/master/client
Currently, the sync is rather complicated (manual) and not at all intuitive
to implement.
Tomaz did great job on BOMs but with his departure nothing is really
happening in this area.

Possible approaches:
1) wildfly/boms project could consume the component matrix versions without
any required interaction besides just declaring version of WildFly
component matrix and then building wildfly/boms

2) generating -SNAPSHOT versions of WildFly BOMs as part of WildFly build
(going back I know) ++ publishing just the final BOMs to
https://github.com/wildfly/boms ?

Comments / suggestions ?

Regards.
Rostislav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180515/2aeb56a1/attachment.html 

From emartins at redhat.com  Wed May 16 02:59:39 2018
From: emartins at redhat.com (Eduardo Martins)
Date: Wed, 16 May 2018 07:59:39 +0100
Subject: [wildfly-dev] Generate WildFly BOMs as part of WildFly build
In-Reply-To: <CACa2xU9SpPDgeE2mz-nHVcAOxoG39n35yC36x8Ym9ubNSjbbaw@mail.gmail.com>
References: <CACa2xU9SpPDgeE2mz-nHVcAOxoG39n35yC36x8Ym9ubNSjbbaw@mail.gmail.com>
Message-ID: <3A910421-1B8E-4F52-9A78-47A024989E4F@redhat.com>


> On 15 May 2018, at 12:28, Rostislav Svoboda <rsvoboda at redhat.com> wrote:
> 
> Hi team.
> 
> WildFly and WildFly core generate component-matrix as part of the build now.
>   https://issues.jboss.org/browse/WFLY-10365 <https://issues.jboss.org/browse/WFLY-10365>
> We should also consider automated propagation of current WildFly master component versions into WildFly BOMs - https://github.com/wildfly/boms <https://github.com/wildfly/boms>. I'm especially interested in https://github.com/wildfly/boms/tree/master/client <https://github.com/wildfly/boms/tree/master/client>Currently, the sync is rather complicated (manual) and not at all intuitive to implement.
> Tomaz did great job on BOMs but with his departure nothing is really happening in this area.
> 

FYI https://github.com/emmartins/boms/tree/component-matrix

Unfortunately there are still a few manual dependencies needed to be declared atm, cause if we import the component matrix (CM) in a BOM dependency management, e.g. wildly-tools, it will add all CM dependencies. BOM ?import" only allows configuration of exclusions, not inclusions?

A possible workaround is to enhance the BOM builder plugin with ?includes? functionality, this way the BOMs project could split CM into smaller BOM CMs, each declaring only the dependencies needed by a BOM, which would then import it.

By the way additional BOMs providing the EE8 APIs supported by WFLY 13 are also incoming.

?E

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

From tomaz.cerar at gmail.com  Thu May 17 10:41:03 2018
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Thu, 17 May 2018 16:41:03 +0200
Subject: [wildfly-dev] Generate WildFly BOMs as part of WildFly build
In-Reply-To: <CACa2xU9SpPDgeE2mz-nHVcAOxoG39n35yC36x8Ym9ubNSjbbaw@mail.gmail.com>
References: <CACa2xU9SpPDgeE2mz-nHVcAOxoG39n35yC36x8Ym9ubNSjbbaw@mail.gmail.com>
Message-ID: <CAMquZP5VsVwXkhn6MFpV1ykPfPB5oD8Xx3M4w4KPofYA_MsR8Q@mail.gmail.com>

> Possible approaches:
> 1) wildfly/boms project could consume the component matrix versions
without any required interaction besides just declaring version of WildFly
component matrix and then building wildfly/boms

keep in mind that having wildfly/boms seperate from wildfly main release
lifecycle is and welcome addition.
Quickstarts depend solely on boms, and as such should be avalible before
WildFly server release is done, so QS can be developed and tested (also on
OpenShift)

--
tomaz


On Tue, May 15, 2018 at 1:28 PM, Rostislav Svoboda <rsvoboda at redhat.com>
wrote:

> Hi team.
>
> WildFly and WildFly core generate component-matrix as part of the build
> now.
>   https://issues.jboss.org/browse/WFLY-10365
>
> We should also consider automated propagation of current WildFly master
> component versions into WildFly BOMs - https://github.com/wildfly/boms.
> I'm especially interested in https://github.com/wildfly/
> boms/tree/master/client
> Currently, the sync is rather complicated (manual) and not at all
> intuitive to implement.
> Tomaz did great job on BOMs but with his departure nothing is really
> happening in this area.
>
> Possible approaches:
> 1) wildfly/boms project could consume the component matrix versions
> without any required interaction besides just declaring version of WildFly
> component matrix and then building wildfly/boms
>
> 2) generating -SNAPSHOT versions of WildFly BOMs as part of WildFly build
> (going back I know) ++ publishing just the final BOMs to
> https://github.com/wildfly/boms ?
>
> Comments / suggestions ?
>
> Regards.
> Rostislav
>
> _______________________________________________
> 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/20180517/f4d53078/attachment.html 

From jperkins at redhat.com  Thu May 17 20:02:49 2018
From: jperkins at redhat.com (James Perkins)
Date: Thu, 17 May 2018 17:02:49 -0700
Subject: [wildfly-dev] WildFly 13.0.0.Beta1 Released
Message-ID: <CADGwLpjGypCVx4kQxkBHiVK+c08F2CCYQpSiMs3kmXCEn72sJA@mail.gmail.com>

Hello All,
WildFly 13.0.0.Beta1 has been released. It can be downloaded here [1].

[1]: http://wildfly.org/downloads/

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

From rsvoboda at redhat.com  Fri May 18 03:26:03 2018
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Fri, 18 May 2018 09:26:03 +0200
Subject: [wildfly-dev] Generate WildFly BOMs as part of WildFly build
In-Reply-To: <CAMquZP5VsVwXkhn6MFpV1ykPfPB5oD8Xx3M4w4KPofYA_MsR8Q@mail.gmail.com>
References: <CACa2xU9SpPDgeE2mz-nHVcAOxoG39n35yC36x8Ym9ubNSjbbaw@mail.gmail.com>
	<CAMquZP5VsVwXkhn6MFpV1ykPfPB5oD8Xx3M4w4KPofYA_MsR8Q@mail.gmail.com>
Message-ID: <CACa2xU9=f4K9v0+iRigYT7Xu6ZDf4CS0MDASp5FhY1Vn8hO_+g@mail.gmail.com>

OK, so we need both independence and quick/easy/automated way to used the
same versions in BOMs as in wf component matrix.

To keep the wf boms independent of wf component matrix we would probably
need explicitely defined versions in BOMs + bom-generator similar to
https://github.com/wildfly/wildfly-component-matrix-plugin which consumes
wf component matrix when needed.

Rostislav



On Thu, May 17, 2018 at 4:41 PM, Toma? Cerar <tomaz.cerar at gmail.com> wrote:

> > Possible approaches:
> > 1) wildfly/boms project could consume the component matrix versions
> without any required interaction besides just declaring version of WildFly
> component matrix and then building wildfly/boms
>
> keep in mind that having wildfly/boms seperate from wildfly main release
> lifecycle is and welcome addition.
> Quickstarts depend solely on boms, and as such should be avalible before
> WildFly server release is done, so QS can be developed and tested (also on
> OpenShift)
>
> --
> tomaz
>
>
> On Tue, May 15, 2018 at 1:28 PM, Rostislav Svoboda <rsvoboda at redhat.com>
> wrote:
>
>> Hi team.
>>
>> WildFly and WildFly core generate component-matrix as part of the build
>> now.
>>   https://issues.jboss.org/browse/WFLY-10365
>>
>> We should also consider automated propagation of current WildFly master
>> component versions into WildFly BOMs - https://github.com/wildfly/boms.
>> I'm especially interested in https://github.com/wildfly/bom
>> s/tree/master/client
>> Currently, the sync is rather complicated (manual) and not at all
>> intuitive to implement.
>> Tomaz did great job on BOMs but with his departure nothing is really
>> happening in this area.
>>
>> Possible approaches:
>> 1) wildfly/boms project could consume the component matrix versions
>> without any required interaction besides just declaring version of WildFly
>> component matrix and then building wildfly/boms
>>
>> 2) generating -SNAPSHOT versions of WildFly BOMs as part of WildFly build
>> (going back I know) ++ publishing just the final BOMs to
>> https://github.com/wildfly/boms ?
>>
>> Comments / suggestions ?
>>
>> Regards.
>> Rostislav
>>
>> _______________________________________________
>> 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/20180518/9a99fb7e/attachment.html 

From emartins at redhat.com  Fri May 18 04:48:28 2018
From: emartins at redhat.com (Eduardo Martins)
Date: Fri, 18 May 2018 09:48:28 +0100
Subject: [wildfly-dev] Generate WildFly BOMs as part of WildFly build
In-Reply-To: <CACa2xU9=f4K9v0+iRigYT7Xu6ZDf4CS0MDASp5FhY1Vn8hO_+g@mail.gmail.com>
References: <CACa2xU9SpPDgeE2mz-nHVcAOxoG39n35yC36x8Ym9ubNSjbbaw@mail.gmail.com>
	<CAMquZP5VsVwXkhn6MFpV1ykPfPB5oD8Xx3M4w4KPofYA_MsR8Q@mail.gmail.com>
	<CACa2xU9=f4K9v0+iRigYT7Xu6ZDf4CS0MDASp5FhY1Vn8hO_+g@mail.gmail.com>
Message-ID: <CALX1fhe_5J9YK7LxZXf5KbJ9OuEvfJ1mt2D3WLOc0Rj_Jfq2Ow@mail.gmail.com>

Honestly I am not sure it?s worth the risks (which Petr implied), trials
with quickstarts with boms from my branch using the component-matrix
resulted in some issues. If it turns out we need to add exclusions it?s not
an improvement over explicit defining dependencies, which could be seen as
?inclusions?.

?E

On Fri, 18 May 2018 at 08:27, Rostislav Svoboda <rsvoboda at redhat.com> wrote:

> OK, so we need both independence and quick/easy/automated way to used the
> same versions in BOMs as in wf component matrix.
>
> To keep the wf boms independent of wf component matrix we would probably
> need explicitely defined versions in BOMs + bom-generator similar to
> https://github.com/wildfly/wildfly-component-matrix-plugin which consumes
> wf component matrix when needed.
>
> Rostislav
>
>
>
> On Thu, May 17, 2018 at 4:41 PM, Toma? Cerar <tomaz.cerar at gmail.com>
> wrote:
>
>> > Possible approaches:
>> > 1) wildfly/boms project could consume the component matrix versions
>> without any required interaction besides just declaring version of WildFly
>> component matrix and then building wildfly/boms
>>
>> keep in mind that having wildfly/boms seperate from wildfly main release
>> lifecycle is and welcome addition.
>> Quickstarts depend solely on boms, and as such should be avalible before
>> WildFly server release is done, so QS can be developed and tested (also on
>> OpenShift)
>>
>> --
>> tomaz
>>
>>
>> On Tue, May 15, 2018 at 1:28 PM, Rostislav Svoboda <rsvoboda at redhat.com>
>> wrote:
>>
>>> Hi team.
>>>
>>> WildFly and WildFly core generate component-matrix as part of the build
>>> now.
>>>   https://issues.jboss.org/browse/WFLY-10365
>>>
>>> We should also consider automated propagation of current WildFly master
>>> component versions into WildFly BOMs - https://github.com/wildfly/boms.
>>> I'm especially interested in
>>> https://github.com/wildfly/boms/tree/master/client
>>> Currently, the sync is rather complicated (manual) and not at all
>>> intuitive to implement.
>>> Tomaz did great job on BOMs but with his departure nothing is really
>>> happening in this area.
>>>
>>> Possible approaches:
>>> 1) wildfly/boms project could consume the component matrix versions
>>> without any required interaction besides just declaring version of WildFly
>>> component matrix and then building wildfly/boms
>>>
>>> 2) generating -SNAPSHOT versions of WildFly BOMs as part of WildFly
>>> build (going back I know) ++ publishing just the final BOMs to
>>> https://github.com/wildfly/boms ?
>>>
>>> Comments / suggestions ?
>>>
>>> Regards.
>>> Rostislav
>>>
>>> _______________________________________________
>>> 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/20180518/9413a4c0/attachment-0001.html 

From emartins at redhat.com  Fri May 18 04:49:31 2018
From: emartins at redhat.com (Eduardo Martins)
Date: Fri, 18 May 2018 09:49:31 +0100
Subject: [wildfly-dev] Generate WildFly BOMs as part of WildFly build
In-Reply-To: <CALX1fhe_5J9YK7LxZXf5KbJ9OuEvfJ1mt2D3WLOc0Rj_Jfq2Ow@mail.gmail.com>
References: <CACa2xU9SpPDgeE2mz-nHVcAOxoG39n35yC36x8Ym9ubNSjbbaw@mail.gmail.com>
	<CAMquZP5VsVwXkhn6MFpV1ykPfPB5oD8Xx3M4w4KPofYA_MsR8Q@mail.gmail.com>
	<CACa2xU9=f4K9v0+iRigYT7Xu6ZDf4CS0MDASp5FhY1Vn8hO_+g@mail.gmail.com>
	<CALX1fhe_5J9YK7LxZXf5KbJ9OuEvfJ1mt2D3WLOc0Rj_Jfq2Ow@mail.gmail.com>
Message-ID: <CALX1fhcZ0Sv5VxcXZt-Ttzhqwp7Y06aXhjky25G_8UDk=RGY0g@mail.gmail.com>

I am going to release 13 Beta1 of BOMs and Quickstarts today not using
component-matrix.

?E

On Fri, 18 May 2018 at 09:48, Eduardo Martins <emartins at redhat.com> wrote:

> Honestly I am not sure it?s worth the risks (which Petr implied), trials
> with quickstarts with boms from my branch using the component-matrix
> resulted in some issues. If it turns out we need to add exclusions it?s not
> an improvement over explicit defining dependencies, which could be seen as
> ?inclusions?.
>
> ?E
>
> On Fri, 18 May 2018 at 08:27, Rostislav Svoboda <rsvoboda at redhat.com>
> wrote:
>
>> OK, so we need both independence and quick/easy/automated way to used the
>> same versions in BOMs as in wf component matrix.
>>
>> To keep the wf boms independent of wf component matrix we would probably
>> need explicitely defined versions in BOMs + bom-generator similar to
>> https://github.com/wildfly/wildfly-component-matrix-plugin which
>> consumes wf component matrix when needed.
>>
>> Rostislav
>>
>>
>>
>> On Thu, May 17, 2018 at 4:41 PM, Toma? Cerar <tomaz.cerar at gmail.com>
>> wrote:
>>
>>> > Possible approaches:
>>> > 1) wildfly/boms project could consume the component matrix versions
>>> without any required interaction besides just declaring version of WildFly
>>> component matrix and then building wildfly/boms
>>>
>>> keep in mind that having wildfly/boms seperate from wildfly main release
>>> lifecycle is and welcome addition.
>>> Quickstarts depend solely on boms, and as such should be avalible before
>>> WildFly server release is done, so QS can be developed and tested (also on
>>> OpenShift)
>>>
>>> --
>>> tomaz
>>>
>>>
>>> On Tue, May 15, 2018 at 1:28 PM, Rostislav Svoboda <rsvoboda at redhat.com>
>>> wrote:
>>>
>>>> Hi team.
>>>>
>>>> WildFly and WildFly core generate component-matrix as part of the build
>>>> now.
>>>>   https://issues.jboss.org/browse/WFLY-10365
>>>>
>>>> We should also consider automated propagation of current WildFly master
>>>> component versions into WildFly BOMs - https://github.com/wildfly/boms.
>>>> I'm especially interested in
>>>> https://github.com/wildfly/boms/tree/master/client
>>>> Currently, the sync is rather complicated (manual) and not at all
>>>> intuitive to implement.
>>>> Tomaz did great job on BOMs but with his departure nothing is really
>>>> happening in this area.
>>>>
>>>> Possible approaches:
>>>> 1) wildfly/boms project could consume the component matrix versions
>>>> without any required interaction besides just declaring version of WildFly
>>>> component matrix and then building wildfly/boms
>>>>
>>>> 2) generating -SNAPSHOT versions of WildFly BOMs as part of WildFly
>>>> build (going back I know) ++ publishing just the final BOMs to
>>>> https://github.com/wildfly/boms ?
>>>>
>>>> Comments / suggestions ?
>>>>
>>>> Regards.
>>>> Rostislav
>>>>
>>>> _______________________________________________
>>>> 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/20180518/30e521cd/attachment.html 

From kwills at redhat.com  Fri May 18 15:03:23 2018
From: kwills at redhat.com (Ken Wills)
Date: Fri, 18 May 2018 14:03:23 -0500
Subject: [wildfly-dev] PR template check
In-Reply-To: <CAEEDSKVXkqvonbvyc9QT-sA2gOTP4wxR5GaeOqGxP2UFKa_gYw@mail.gmail.com>
References: <CAEEDSKVXkqvonbvyc9QT-sA2gOTP4wxR5GaeOqGxP2UFKa_gYw@mail.gmail.com>
Message-ID: <CAMw35_oYLf=sXaBhLJunmkawZ6Q91hYDN1n3g07g8uqhQYf0=Q@mail.gmail.com>

On Tue, May 15, 2018 at 4:59 AM Martin Stefanko <mstefank at redhat.com> wrote:

> Hi all,
>

Hi Martin,


>
> I've created a tool [1] that validates the PR format. For now it checks
> the title and the description for the required information configured by
> regex expressions. It runs on my OS online and is configured in [2] on the
> master branch.
>
> The tool uses GH webhooks which needs to be set up in the targeting
> repository and it requires the respective OAuth token, for now configured
> through the OS secret.
>
> This is the basic functionality, I can add more checks later (e.g., link
> validity, number of commits). Any feedback is welcome.
>
> [1] https://github.com/xstefank/tyr
> [2] https://github.com/xstefank/test-repo
> ?
>  tyr.mp4
> <https://drive.google.com/a/redhat.com/file/d/1QCeBSoviD2Xj9ycPjrH8cjwlbwEHcCji/view?usp=drive_web>
> ?
>

This looks like something we could use. What we really, really need is
somethign to maintain (add, at least) a whitelist of users that PRs should
auto run for & the ability to label a PR with OkToTest or something if the
user isn't already in the whitelist.

Is this something you could add to this tool? Does the GH api allow
configuration of checks to only run if the previous ones pass?

Thanks,

Ken



>
> Martin Stefanko
>
> Software Engineer
> JBoss Sustaining Engineering Team
> 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/20180518/826440f8/attachment.html 

From jperkins at redhat.com  Fri May 18 16:39:30 2018
From: jperkins at redhat.com (James Perkins)
Date: Fri, 18 May 2018 13:39:30 -0700
Subject: [wildfly-dev] PR template check
In-Reply-To: <CAMw35_oYLf=sXaBhLJunmkawZ6Q91hYDN1n3g07g8uqhQYf0=Q@mail.gmail.com>
References: <CAEEDSKVXkqvonbvyc9QT-sA2gOTP4wxR5GaeOqGxP2UFKa_gYw@mail.gmail.com>
	<CAMw35_oYLf=sXaBhLJunmkawZ6Q91hYDN1n3g07g8uqhQYf0=Q@mail.gmail.com>
Message-ID: <CADGwLpgnxmpWsd2U_1tg0n0BoXtKc+HVb9DiWM9w4f9U2-MKcA@mail.gmail.com>

One thing it would need to if we do something like this is a way to bypass
the check. Occasionally a JIRA isn't required for a PR. For example the
WildFly Core upgrade in WildFly full we don't generally file a JIRA for.

On Fri, May 18, 2018 at 12:03 PM, Ken Wills <kwills at redhat.com> wrote:

> On Tue, May 15, 2018 at 4:59 AM Martin Stefanko <mstefank at redhat.com>
> wrote:
>
>> Hi all,
>>
>
> Hi Martin,
>
>
>>
>> I've created a tool [1] that validates the PR format. For now it checks
>> the title and the description for the required information configured by
>> regex expressions. It runs on my OS online and is configured in [2] on the
>> master branch.
>>
>> The tool uses GH webhooks which needs to be set up in the targeting
>> repository and it requires the respective OAuth token, for now configured
>> through the OS secret.
>>
>> This is the basic functionality, I can add more checks later (e.g., link
>> validity, number of commits). Any feedback is welcome.
>>
>> [1] https://github.com/xstefank/tyr
>> [2] https://github.com/xstefank/test-repo
>> ?
>>  tyr.mp4
>> <https://drive.google.com/a/redhat.com/file/d/1QCeBSoviD2Xj9ycPjrH8cjwlbwEHcCji/view?usp=drive_web>
>> ?
>>
>
> This looks like something we could use. What we really, really need is
> somethign to maintain (add, at least) a whitelist of users that PRs should
> auto run for & the ability to label a PR with OkToTest or something if the
> user isn't already in the whitelist.
>
> Is this something you could add to this tool? Does the GH api allow
> configuration of checks to only run if the previous ones pass?
>
> Thanks,
>
> Ken
>
>
>
>>
>> Martin Stefanko
>>
>> Software Engineer
>> JBoss Sustaining Engineering Team
>> 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
>



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

From mstefank at redhat.com  Sat May 19 10:50:02 2018
From: mstefank at redhat.com (Martin Stefanko)
Date: Sat, 19 May 2018 16:50:02 +0200
Subject: [wildfly-dev] PR template check
In-Reply-To: <CAMw35_oYLf=sXaBhLJunmkawZ6Q91hYDN1n3g07g8uqhQYf0=Q@mail.gmail.com>
References: <CAEEDSKVXkqvonbvyc9QT-sA2gOTP4wxR5GaeOqGxP2UFKa_gYw@mail.gmail.com>
	<CAMw35_oYLf=sXaBhLJunmkawZ6Q91hYDN1n3g07g8uqhQYf0=Q@mail.gmail.com>
Message-ID: <CAEEDSKVmA2SkRs5TYWaQUh0Qtcd_6Ouh7b2fuzX3X58o3613eQ@mail.gmail.com>

Hi Ken,

This looks like something we could use. What we really, really need is
> somethign to maintain (add, at least) a whitelist of users that PRs should
> auto run for & the ability to label a PR with OkToTest or something if the
> user isn't already in the whitelist.
>

If we decide to move the whitelist setup to this tool (and webhooks) I can
extend it to configure the list dynamically possibly through labels or
comments (something like /whitelist @user). The same applies to the
OkToTest mentions for individual PRs without whitelisting.


>
> Is this something you could add to this tool? Does the GH api allow
> configuration of checks to only run if the previous ones pass?
>

I am using webhooks that are invoked when the PR is changed in any way. The
status checks cannot be removed, otherwise I can update them as needed.

The tool in the repository is now also checking that the PR should contain
only one commit.

Thanks,
Martin Stefanko

Software Engineer
JBoss Sustaining Engineering Team
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180519/c524fe10/attachment.html 

From mstefank at redhat.com  Sat May 19 10:57:49 2018
From: mstefank at redhat.com (Martin Stefanko)
Date: Sat, 19 May 2018 16:57:49 +0200
Subject: [wildfly-dev] PR template check
In-Reply-To: <CADGwLpgnxmpWsd2U_1tg0n0BoXtKc+HVb9DiWM9w4f9U2-MKcA@mail.gmail.com>
References: <CAEEDSKVXkqvonbvyc9QT-sA2gOTP4wxR5GaeOqGxP2UFKa_gYw@mail.gmail.com>
	<CAMw35_oYLf=sXaBhLJunmkawZ6Q91hYDN1n3g07g8uqhQYf0=Q@mail.gmail.com>
	<CADGwLpgnxmpWsd2U_1tg0n0BoXtKc+HVb9DiWM9w4f9U2-MKcA@mail.gmail.com>
Message-ID: <CAEEDSKVz83OWy_m3kKXhg2rEVNvH+gXP342_r0V3pVxg3qmG5w@mail.gmail.com>

Hi James,

One thing it would need to if we do something like this is a way to bypass
> the check. Occasionally a JIRA isn't required for a PR. For example the
> WildFly Core upgrade in WildFly full we don't generally file a JIRA for.
>

This is surely doable, but I would argue that this should be clearly stated
for instance in the PR title or description (e.g., "[NO JIRA] Subject" or
similar). In that way, the check won't be set up.

Thanks,
Martin Stefanko

Software Engineer
JBoss Sustaining Engineering Team
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180519/6604bd0b/attachment.html 

From jperkins at redhat.com  Mon May 21 11:33:32 2018
From: jperkins at redhat.com (James Perkins)
Date: Mon, 21 May 2018 08:33:32 -0700
Subject: [wildfly-dev] PR template check
In-Reply-To: <CAEEDSKVz83OWy_m3kKXhg2rEVNvH+gXP342_r0V3pVxg3qmG5w@mail.gmail.com>
References: <CAEEDSKVXkqvonbvyc9QT-sA2gOTP4wxR5GaeOqGxP2UFKa_gYw@mail.gmail.com>
	<CAMw35_oYLf=sXaBhLJunmkawZ6Q91hYDN1n3g07g8uqhQYf0=Q@mail.gmail.com>
	<CADGwLpgnxmpWsd2U_1tg0n0BoXtKc+HVb9DiWM9w4f9U2-MKcA@mail.gmail.com>
	<CAEEDSKVz83OWy_m3kKXhg2rEVNvH+gXP342_r0V3pVxg3qmG5w@mail.gmail.com>
Message-ID: <CADGwLpjrtdVYySriam0bnwgciFcnBvypfoucpEnbzBYUeVVphg@mail.gmail.com>

Hi Martin,
That definitely seems reasonable. Just some way to bypass it. It shouldn't
be used often, but it does happen for some small changes.

On Sat, May 19, 2018 at 7:57 AM, Martin Stefanko <mstefank at redhat.com>
wrote:

> Hi James,
>
> One thing it would need to if we do something like this is a way to bypass
>> the check. Occasionally a JIRA isn't required for a PR. For example the
>> WildFly Core upgrade in WildFly full we don't generally file a JIRA for.
>>
>
> This is surely doable, but I would argue that this should be clearly
> stated for instance in the PR title or description (e.g., "[NO JIRA]
> Subject" or similar). In that way, the check won't be set up.
>
> Thanks,
> Martin Stefanko
>
> Software Engineer
> JBoss Sustaining Engineering Team
> 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/20180521/8a67f850/attachment.html 

From rsearls at redhat.com  Wed May 23 14:53:27 2018
From: rsearls at redhat.com (Rebecca Searls)
Date: Wed, 23 May 2018 14:53:27 -0400
Subject: [wildfly-dev] wfly bin\*.conf.ps1 files question
Message-ID: <CAM_r5cgPHZEEuN1Yn0hhc8GBVf_H3PvePdVMNJTsr7TLv8om4Q@mail.gmail.com>

I don't understand the reason for setting the (local) variable JAVA_OPTS
in the *.conf.ps1 files when the common.ps1 functions completely ignores
the local setting and always reads and uses the environment variable value.

The in-file comments leads the reader to believe he can override the system
env var and define a new JAVA_OPTS in the conf file which will be used by
the
calling script.  Currently this is not true.

Can someone explain the intent here?  Is this a bug or obsolete code that
should be removed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180523/6e6fe5d9/attachment.html 

From tomaz.cerar at gmail.com  Fri May 25 04:12:35 2018
From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=)
Date: Fri, 25 May 2018 10:12:35 +0200
Subject: [wildfly-dev] wfly bin\*.conf.ps1 files question
In-Reply-To: <CAM_r5cgPHZEEuN1Yn0hhc8GBVf_H3PvePdVMNJTsr7TLv8om4Q@mail.gmail.com>
References: <CAM_r5cgPHZEEuN1Yn0hhc8GBVf_H3PvePdVMNJTsr7TLv8om4Q@mail.gmail.com>
Message-ID: <CAMquZP65_mk5W_OXF4OdRGmr-5oN7adExYqPEvgoJ=-zSb7o2Q@mail.gmail.com>

Hey Rebecca,

I've initially wrote that script but to be fair I do not really remember
reasoning behind every detail...

But one thing I do remember is that enviroment variables have different
scopes.
and should not be equaled to how env variables in powershell work comparing
to linux.

So you have scopes which can be
- system enviroment, (which can differ as per user/per whole system)
- script local (bit special with imports/includes)
- process local

and I do remember I did play around with process scope a bit to get some
stuff working.

Main goal was to have common.ps1 that would have common logic for all
scripts.
and than the actual scripts (standalone.ps1, jboss-cli.ps1,...) would just
have the extra specifics.

One thing I was also looking into was creating common.ps1 as a powershell
module [1] [2],
that would server as that "common" part and it would simplify things even
more.
But I never got to finishing it.

I know this is all really vague, but I still hope it will help a bit.

cheers,
tomaz

[1] https://msdn.microsoft.com/en-us/library/dd878340(v=vs.85).aspx
[2] https://msdn.microsoft.com/en-us/library/dd878324(v=vs.85).aspx



On Wed, May 23, 2018 at 8:53 PM, Rebecca Searls <rsearls at redhat.com> wrote:

>
> I don't understand the reason for setting the (local) variable JAVA_OPTS
> in the *.conf.ps1 files when the common.ps1 functions completely ignores
> the local setting and always reads and uses the environment variable value.
>
> The in-file comments leads the reader to believe he can override the system
> env var and define a new JAVA_OPTS in the conf file which will be used by
> the
> calling script.  Currently this is not true.
>
> Can someone explain the intent here?  Is this a bug or obsolete code that
> should be removed?
>
>
> _______________________________________________
> 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/20180525/3e53dc92/attachment.html 

From mwessend at redhat.com  Sat May 26 03:46:20 2018
From: mwessend at redhat.com (Matthias Wessendorf)
Date: Sat, 26 May 2018 09:46:20 +0200
Subject: [wildfly-dev] k8s operator for WildFly
Message-ID: <CAKUFdH3qhNnbxF4c5=_EV0EDjhowZwUTr62i=H_oMMO_QvKFHg@mail.gmail.com>

on the CoreOS 'operator-framework' org, I saw that there is a k8s operator
for the WildFly server:

https://github.com/banzaicloud/wildfly-operator

anyone seen or used it ?

Cheers,
Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180526/26facacb/attachment-0001.html 

From elayaraja.s at gmail.com  Tue May 29 03:25:03 2018
From: elayaraja.s at gmail.com (wildflyuser)
Date: Tue, 29 May 2018 00:25:03 -0700 (MST)
Subject: [wildfly-dev] Upgrade jboss.7.1.1 to wildfly.9.0.2: WFLYCTL0180:
 Services with missing/unavailable dependencies
Message-ID: <1527578703995-0.post@n5.nabble.com>

Upgrade jboss.7.1.1 to wildfly.9.0.2: WFLYCTL0180: Services with
missing/unavailable dependencies

2018-05-29 12:05:54,264 ERROR [org.jboss.as.controller.management-operation]
(Controller Boot Thread) WFLYCTL0013: Operation ("deploy") failed - address:
([("deployment" => "adapters.ear")]) - failure description: {"WFLYCTL0288:
One or more services were unable to start due to one or more indirect
dependencies not being available." => {
    "Services that were unable to start:" => [
       
"jboss.deployment.subunit.\"adapters.ear\".\"modules.war\".component.\"com.sun.faces.config.ConfigureListener\".START",
       
"jboss.deployment.subunit.\"adapters.ear\".\"modules.war\".component.\"javax.faces.webapp.FacetTag\".START",
       
"jboss.deployment.subunit.\"adapters.ear\".\"modules.war\".component.\"javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV\".START",
       
"jboss.deployment.subunit.\"adapters.ear\".\"modules.war\".component.\"javax.servlet.jsp.jstl.tlv.ScriptFreeTLV\".START",
       
"jboss.deployment.subunit.\"adapters.ear\".\"modules.war\".deploymentCompleteService",
       
"jboss.deployment.subunit.\"adapters.ear\".\"modules.war\".ejb3.client-context.registration-service",
        "jboss.deployment.unit.\"adapters.ear\".deploymentCompleteService",
       
"jboss.deployment.unit.\"adapters.ear\".ejb3.client-context.registration-service",
        "jboss.naming.context.java.module.adaptersapp.modules.ORB",
        "jboss.undertow.deployment.default-server.default-host./modules",
       
"jboss.undertow.deployment.default-server.default-host./modules.UndertowDeploymentInfoService"
    ],
    "Services that may be the cause:" => [
        "jboss.binding.iiop",
        "jboss.binding.iiop-ssl",
       
"jboss.remoting.remotingConnectorInfoService.http-remoting-connector"
    ]
}}
2018-05-29 12:05:54,277 ERROR [org.jboss.as.controller.management-operation]
(Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address:
([("subsystem" => "iiop-openjdk")]) - failure description: {
    "WFLYCTL0180: Services with missing/unavailable dependencies" =>
["jboss.iiop-openjdk.orb-service is missing [jboss.binding.iiop,
jboss.binding.iiop-ssl]"],
    "WFLYCTL0288: One or more services were unable to start due to one or
more indirect dependencies not being available." => {
        "Services that were unable to start:" => [
            "jboss.iiop-openjdk.naming-service",
            "jboss.iiop-openjdk.poa-service.irpoa",
            "jboss.iiop-openjdk.poa-service.namingpoa",
            "jboss.iiop-openjdk.poa-service.rootpoa"
        ],
        "Services that may be the cause:" => [
            "jboss.binding.iiop",
            "jboss.binding.iiop-ssl",
           
"jboss.remoting.remotingConnectorInfoService.http-remoting-connector"
        ]
    }
}
2018-05-29 12:05:54,285 ERROR [org.jboss.as.controller.management-operation]
(Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address:
([("subsystem" => "jsr77")]) - failure description: {"WFLYCTL0288: One or
more services were unable to start due to one or more indirect dependencies
not being available." => {
    "Services that were unable to start:" => ["jboss.jsr77.ejb"],
    "Services that may be the cause:" => [
        "jboss.binding.iiop",
        "jboss.binding.iiop-ssl",
       
"jboss.remoting.remotingConnectorInfoService.http-remoting-connector"
    ]
}}
2018-05-29 12:05:54,292 ERROR [org.jboss.as.controller.management-operation]
(Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address:
([("subsystem" => "ejb3")]) - failure description: {"WFLYCTL0288: One or
more services were unable to start due to one or more indirect dependencies
not being available." => {
    "Services that were unable to start:" => [
        "jboss.ejb.default-local-ejb-receiver-service",
        "jboss.ejb3.ejbClientContext.default",
        "jboss.ejb3.localEjbReceiver.value"
    ],
    "Services that may be the cause:" => [
        "jboss.binding.iiop",
        "jboss.binding.iiop-ssl",
       
"jboss.remoting.remotingConnectorInfoService.http-remoting-connector"
    ]
}}
2018-05-29 12:05:54,298 ERROR [org.jboss.as.controller.management-operation]
(Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "ejb3"),
    ("service" => "remote")
]) - failure description: {
    "WFLYCTL0180: Services with missing/unavailable dependencies" => [
        "jboss.ejb3.connector is missing
[jboss.remoting.remotingConnectorInfoService.http-remoting-connector]",
        "jboss.clustering.registry.ejb.default.entry is missing
[jboss.remoting.remotingConnectorInfoService.http-remoting-connector]"
    ],
    "WFLYCTL0288: One or more services were unable to start due to one or
more indirect dependencies not being available." => {
        "Services that were unable to start:" =>
["jboss.ejb.remoting.connector.client-mappings.installer"],
        "Services that may be the cause:" => [
            "jboss.binding.iiop",
            "jboss.binding.iiop-ssl",
           
"jboss.remoting.remotingConnectorInfoService.http-remoting-connector"
        ]
    }
}
2018-05-29 12:05:54,305 ERROR [org.jboss.as.controller.management-operation]
(Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "infinispan"),
    ("cache-container" => "ejb")
]) - failure description: {"WFLYCTL0288: One or more services were unable to
start due to one or more indirect dependencies not being available." => {
    "Services that were unable to start:" =>
["jboss.clustering.registry.ejb.default"],
    "Services that may be the cause:" => [
        "jboss.binding.iiop",
        "jboss.binding.iiop-ssl",
       
"jboss.remoting.remotingConnectorInfoService.http-remoting-connector"
    ]
}}
2018-05-29 12:05:55,041 ERROR [org.jboss.as] (Controller Boot Thread)
WFLYSRV0026: WildFly Full 9.0.2.Final (WildFly Core 1.0.2.Final) started
(with errors) in 26497ms - Started 5269 of 7641 services (2109 services
failed or missing dependencies, 413 services are lazy, passive or on-demand)



--
Sent from: http://wildfly-development.1055759.n5.nabble.com/

From elayaraja.s at gmail.com  Tue May 29 03:26:03 2018
From: elayaraja.s at gmail.com (wildflyuser)
Date: Tue, 29 May 2018 00:26:03 -0700 (MST)
Subject: [wildfly-dev] Upgade from jboss-as-7.1.1.Final to
	wildfly-9.0.2.Final
Message-ID: <1527578763182-0.post@n5.nabble.com>

For upgrade from jboss-as-7.1.1.Final to wildfly-9.0.2.Final, do we need to
follow any steps, it will be helpful for us.



--
Sent from: http://wildfly-development.1055759.n5.nabble.com/

From elayaraja.s at gmail.com  Tue May 29 04:51:25 2018
From: elayaraja.s at gmail.com (wildflyuser)
Date: Tue, 29 May 2018 01:51:25 -0700 (MST)
Subject: [wildfly-dev] wildfly-9.0.2.Final: Failed to start service
 jboss.deployment.unit."app.ear".WeldStartService:
Message-ID: <1527583885960-0.post@n5.nabble.com>

Not sure what we are missing, getting below error. Upraded from
jboss-as-7.1.1.Final  to wildfly-9.0.2.Final

 

ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001:
Failed to start service jboss.deployment.unit."app.ear".WeldStartService:
org.jboss.msc.service.StartException in service
jboss.deployment.unit."app.ear".WeldStartService: Failed to start service

    at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)

    at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

    at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

    at java.lang.Thread.run(Thread.java:745)

Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408:
Unsatisfied dependencies for type ServiceLocator with qualifiers @Default

  at injection point [UnbackedAnnotatedField] @Inject private
org.glassfish.jersey.server.mvc.internal.ViewableMessageBodyWriter.serviceLocator

  at
org.glassfish.jersey.server.mvc.internal.ViewableMessageBodyWriter.serviceLocator(ViewableMessageBodyWriter.java:0)

 

    at
org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)

    at
org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)

    at
org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)

    at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)

    at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)

    at
org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)

    at
org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)

    at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)

    at
org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)

    at java.util.concurrent.FutureTask.run(FutureTask.java:262)



--
Sent from: http://wildfly-development.1055759.n5.nabble.com/

From elayaraja.s at gmail.com  Tue May 29 05:11:55 2018
From: elayaraja.s at gmail.com (wildflyuser)
Date: Tue, 29 May 2018 02:11:55 -0700 (MST)
Subject: [wildfly-dev] Is there any change in module concepts between jboss
	and wildfly
Message-ID: <1527585115777-0.post@n5.nabble.com>

1) Is there any change in module concepts between jboss and wildfly ?
2) In jobss we have folder as <JBossHome>/modules in wildfly
<wildfly_home_9.0.2>modules/system/layers/base. Is there any difference ?
3) As part of upgrade if we reuse/copy folder from <JBossHome>/modules to
<wildfly_home_9.0.2>modules/  
   so that my deployed application should consider only modules from
<wildfly_home_9.0.2>modules/  and it should not consider
<wildfly_home_9.0.2>modules/system/layers/base
   Which will make the upgrade easier to proceed step by step.



--
Sent from: http://wildfly-development.1055759.n5.nabble.com/

From rory.odonnell at oracle.com  Tue May 29 05:53:47 2018
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Tue, 29 May 2018 10:53:47 +0100
Subject: [wildfly-dev] JDK 11 Early Access build 15 is available for
	download.
Message-ID: <8f12f580-dbd2-de49-2c00-6b6b63fe89b9@oracle.com>

Hi Jason/Tomaz,

**JDK 11 EA build 15 , *****under both the GPL and Oracle EA licenses, 
is now available at **http://jdk.java.net/11**. **
*

  * Newly approved Schedule, status & features
      o http://openjdk.java.net/projects/jdk/11/
  * Release Notes:
      o http://jdk.java.net/11/release-notes
  * Summary of changes
      o http://jdk.java.net/11/changes

*Notable changes in JDK 11 EA builds since last email:*

  * b15 - JDK-8201627 <http://bugs.openjdk.java.net/browse/JDK-8201627>
    - Kerberos sequence number issues
  * b13 - JDK-8200146 <http://bugs.openjdk.java.net/browse/JDK-8200146>
    - Removal of appletviewer launcher
      o deprecated in JDK 9 and has been removed in this release
  * b13 - JDK-8201793 <http://bugs.openjdk.java.net/browse/JDK-8201793>
    - java.lang.ref.Reference does not support cloning

**

**

JEPs proposed to target JDK 11 (review ends 2018/05/31 23:00 UTC)

    330: Launch Single-File Source-Code Programs
    <http://openjdk.java.net/jeps/330>

    JEPs targeted to JDK 11, so far

    309: Dynamic Class-File Constants <http://openjdk.java.net/jeps/309>
    318: Epsilon: A No-Op Garbage Collector
    <http://openjdk.java.net/jeps/318>
    320: Remove the Java EE and CORBA Modules
    <http://openjdk.java.net/jeps/320>
    321: HTTP Client (Standard) <http://openjdk.java.net/jeps/321>
    323: Local-Variable Syntax for Lambda Parameters
    <http://openjdk.java.net/jeps/323>
    324: Key Agreement with Curve25519 and Curve448
    <http://openjdk.java.net/jeps/324>
    327: Unicode 10 <http://openjdk.java.net/jeps/327>
    328: Flight Recorder <http://openjdk.java.net/jeps/328>
    329: ChaCha20 and Poly1305 Cryptographic Algorithms
    <http://openjdk.java.net/jeps/329>

Finally, Initial TLSv1.3 implementation Released to the Open Sandbox. 
Please note well: this branch is under
very active development and is not final by any means. Also note: by 
releasing this code, we are not committing
a specific release or timeframe. We will continue development and fixing 
bugs until the code is ready for inclusion
in the JDK. We welcome your feedback, more info [1]


Regards,
Rory

[1] 
http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html

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

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

From manovotn at redhat.com  Tue May 29 06:06:02 2018
From: manovotn at redhat.com (Matej Novotny)
Date: Tue, 29 May 2018 06:06:02 -0400 (EDT)
Subject: [wildfly-dev] wildfly-9.0.2.Final: Failed to start service
 jboss.deployment.unit."app.ear".WeldStartService:
In-Reply-To: <1527583885960-0.post@n5.nabble.com>
References: <1527583885960-0.post@n5.nabble.com>
Message-ID: <2027596710.37876760.1527588362609.JavaMail.zimbra@redhat.com>

Hello,

while upgrading from AS 7.1 to WFLY 9, you updated Weld from 1.x to 2.x and I bet there was also major upgrade in Jersey.
You might want to check the migration notes of those two and then probably read up on jersey integration with CDI/Weld.

Weld changes don't seem to be causing this though.
If I were you I would try and identify the Jersey versions in both servers and go from there.

One last thing - note that you are basically upgrading from pre-historic version to outdated one (3y old); currently, there is WildFly 12 as the latest release.
As you will likely face many migration difficulties, it may be worth it to instead look into migration to latest WildFly right away.
Though I understand it may not be possible in your case for various reasons.

Regards
Matej

----- Original Message -----
> From: "wildflyuser" <elayaraja.s at gmail.com>
> To: wildfly-dev at lists.jboss.org
> Sent: Tuesday, May 29, 2018 10:51:25 AM
> Subject: [wildfly-dev] wildfly-9.0.2.Final: Failed to start service jboss.deployment.unit."app.ear".WeldStartService:
> 
> Not sure what we are missing, getting below error. Upraded from
> jboss-as-7.1.1.Final  to wildfly-9.0.2.Final
> 
>  
> 
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001:
> Failed to start service jboss.deployment.unit."app.ear".WeldStartService:
> org.jboss.msc.service.StartException in service
> jboss.deployment.unit."app.ear".WeldStartService: Failed to start service
> 
>     at
> org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 
>     at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 
>     at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 
>     at java.lang.Thread.run(Thread.java:745)
> 
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408:
> Unsatisfied dependencies for type ServiceLocator with qualifiers @Default
> 
>   at injection point [UnbackedAnnotatedField] @Inject private
> org.glassfish.jersey.server.mvc.internal.ViewableMessageBodyWriter.serviceLocator
> 
>   at
> org.glassfish.jersey.server.mvc.internal.ViewableMessageBodyWriter.serviceLocator(ViewableMessageBodyWriter.java:0)
> 
>  
> 
>     at
> org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359)
> 
>     at
> org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281)
> 
>     at
> org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134)
> 
>     at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155)
> 
>     at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518)
> 
>     at
> org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
> 
>     at
> org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
> 
>     at
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> 
>     at
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> 
>     at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> 
> 
> 
> --
> Sent from: http://wildfly-development.1055759.n5.nabble.com/
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 

From elayaraja.s at gmail.com  Tue May 29 06:14:35 2018
From: elayaraja.s at gmail.com (ElayaRaja S)
Date: Tue, 29 May 2018 15:44:35 +0530
Subject: [wildfly-dev] wildfly-9.0.2.Final: Failed to start service
	jboss.deployment.unit."app.ear".WeldStartService:
In-Reply-To: <2027596710.37876760.1527588362609.JavaMail.zimbra@redhat.com>
References: <1527583885960-0.post@n5.nabble.com>
	<2027596710.37876760.1527588362609.JavaMail.zimbra@redhat.com>
Message-ID: <CAJbBuQLO6Lqsn7aQ7O7J3yj5fd2Tv6+aXamh_boFC9P75gayFg@mail.gmail.com>

Thanks for your reply. Yes your right the reason why we have choose
wildfly9.0.2.Final is,  currently our application has been devloped with
jdk1.7.0_72


On Tue, May 29, 2018 at 3:36 PM, Matej Novotny <manovotn at redhat.com> wrote:

> Hello,
>
> while upgrading from AS 7.1 to WFLY 9, you updated Weld from 1.x to 2.x
> and I bet there was also major upgrade in Jersey.
> You might want to check the migration notes of those two and then probably
> read up on jersey integration with CDI/Weld.
>
> Weld changes don't seem to be causing this though.
> If I were you I would try and identify the Jersey versions in both servers
> and go from there.
>
> One last thing - note that you are basically upgrading from pre-historic
> version to outdated one (3y old); currently, there is WildFly 12 as the
> latest release.
> As you will likely face many migration difficulties, it may be worth it to
> instead look into migration to latest WildFly right away.
> Though I understand it may not be possible in your case for various
> reasons.
>
> Regards
> Matej
>
> ----- Original Message -----
> > From: "wildflyuser" <elayaraja.s at gmail.com>
> > To: wildfly-dev at lists.jboss.org
> > Sent: Tuesday, May 29, 2018 10:51:25 AM
> > Subject: [wildfly-dev] wildfly-9.0.2.Final: Failed to start service
> jboss.deployment.unit."app.ear".WeldStartService:
> >
> > Not sure what we are missing, getting below error. Upraded from
> > jboss-as-7.1.1.Final  to wildfly-9.0.2.Final
> >
> >
> >
> > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001:
> > Failed to start service jboss.deployment.unit."app.
> ear".WeldStartService:
> > org.jboss.msc.service.StartException in service
> > jboss.deployment.unit."app.ear".WeldStartService: Failed to start
> service
> >
> >     at
> > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(
> ServiceControllerImpl.java:1904)
> >
> >     at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1145)
> >
> >     at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:615)
> >
> >     at java.lang.Thread.run(Thread.java:745)
> >
> > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408:
> > Unsatisfied dependencies for type ServiceLocator with qualifiers @Default
> >
> >   at injection point [UnbackedAnnotatedField] @Inject private
> > org.glassfish.jersey.server.mvc.internal.ViewableMessageBodyWriter.
> serviceLocator
> >
> >   at
> > org.glassfish.jersey.server.mvc.internal.ViewableMessageBodyWriter.
> serviceLocator(ViewableMessageBodyWriter.java:0)
> >
> >
> >
> >     at
> > org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeplo
> ymentProblems(Validator.java:359)
> >
> >     at
> > org.jboss.weld.bootstrap.Validator.validateInjectionPoint(
> Validator.java:281)
> >
> >     at
> > org.jboss.weld.bootstrap.Validator.validateGeneralBean(
> Validator.java:134)
> >
> >     at org.jboss.weld.bootstrap.Validator.validateRIBean(
> Validator.java:155)
> >
> >     at org.jboss.weld.bootstrap.Validator.validateBean(
> Validator.java:518)
> >
> >     at
> > org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(
> ConcurrentValidator.java:68)
> >
> >     at
> > org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(
> ConcurrentValidator.java:66)
> >
> >     at
> > org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(
> IterativeWorkerTaskFactory.java:60)
> >
> >     at
> > org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(
> IterativeWorkerTaskFactory.java:53)
> >
> >     at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> >
> >
> >
> > --
> > Sent from: http://wildfly-development.1055759.n5.nabble.com/
> > _______________________________________________
> > 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/20180529/210acec5/attachment.html 

From manovotn at redhat.com  Tue May 29 06:42:59 2018
From: manovotn at redhat.com (Matej Novotny)
Date: Tue, 29 May 2018 06:42:59 -0400 (EDT)
Subject: [wildfly-dev] wildfly-9.0.2.Final: Failed to start service
 jboss.deployment.unit."app.ear".WeldStartService:
In-Reply-To: <CAJbBuQLO6Lqsn7aQ7O7J3yj5fd2Tv6+aXamh_boFC9P75gayFg@mail.gmail.com>
References: <1527583885960-0.post@n5.nabble.com>
	<2027596710.37876760.1527588362609.JavaMail.zimbra@redhat.com>
	<CAJbBuQLO6Lqsn7aQ7O7J3yj5fd2Tv6+aXamh_boFC9P75gayFg@mail.gmail.com>
Message-ID: <1681935240.37888444.1527590579774.JavaMail.zimbra@redhat.com>

Hmm, from what I can recall, you need JDK 8+ for Wildfly 8 and above anyway.

Matej

----- Original Message -----
> From: "ElayaRaja S" <elayaraja.s at gmail.com>
> To: "Matej Novotny" <manovotn at redhat.com>
> Cc: wildfly-dev at lists.jboss.org
> Sent: Tuesday, May 29, 2018 12:14:35 PM
> Subject: Re: [wildfly-dev] wildfly-9.0.2.Final: Failed to start service
> jboss.deployment.unit."app.ear".WeldStartService:
> 
> Thanks for your reply. Yes your right the reason why we have choose
> wildfly9.0.2.Final is,  currently our application has been devloped with
> jdk1.7.0_72
> 
> 
> On Tue, May 29, 2018 at 3:36 PM, Matej Novotny <manovotn at redhat.com> wrote:
> 
> > Hello,
> >
> > while upgrading from AS 7.1 to WFLY 9, you updated Weld from 1.x to 2.x
> > and I bet there was also major upgrade in Jersey.
> > You might want to check the migration notes of those two and then probably
> > read up on jersey integration with CDI/Weld.
> >
> > Weld changes don't seem to be causing this though.
> > If I were you I would try and identify the Jersey versions in both servers
> > and go from there.
> >
> > One last thing - note that you are basically upgrading from pre-historic
> > version to outdated one (3y old); currently, there is WildFly 12 as the
> > latest release.
> > As you will likely face many migration difficulties, it may be worth it to
> > instead look into migration to latest WildFly right away.
> > Though I understand it may not be possible in your case for various
> > reasons.
> >
> > Regards
> > Matej
> >
> > ----- Original Message -----
> > > From: "wildflyuser" <elayaraja.s at gmail.com>
> > > To: wildfly-dev at lists.jboss.org
> > > Sent: Tuesday, May 29, 2018 10:51:25 AM
> > > Subject: [wildfly-dev] wildfly-9.0.2.Final: Failed to start service
> > jboss.deployment.unit."app.ear".WeldStartService:
> > >
> > > Not sure what we are missing, getting below error. Upraded from
> > > jboss-as-7.1.1.Final  to wildfly-9.0.2.Final
> > >
> > >
> > >
> > > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001:
> > > Failed to start service jboss.deployment.unit."app.
> > ear".WeldStartService:
> > > org.jboss.msc.service.StartException in service
> > > jboss.deployment.unit."app.ear".WeldStartService: Failed to start
> > service
> > >
> > >     at
> > > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(
> > ServiceControllerImpl.java:1904)
> > >
> > >     at
> > > java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1145)
> > >
> > >     at
> > > java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:615)
> > >
> > >     at java.lang.Thread.run(Thread.java:745)
> > >
> > > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408:
> > > Unsatisfied dependencies for type ServiceLocator with qualifiers @Default
> > >
> > >   at injection point [UnbackedAnnotatedField] @Inject private
> > > org.glassfish.jersey.server.mvc.internal.ViewableMessageBodyWriter.
> > serviceLocator
> > >
> > >   at
> > > org.glassfish.jersey.server.mvc.internal.ViewableMessageBodyWriter.
> > serviceLocator(ViewableMessageBodyWriter.java:0)
> > >
> > >
> > >
> > >     at
> > > org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeplo
> > ymentProblems(Validator.java:359)
> > >
> > >     at
> > > org.jboss.weld.bootstrap.Validator.validateInjectionPoint(
> > Validator.java:281)
> > >
> > >     at
> > > org.jboss.weld.bootstrap.Validator.validateGeneralBean(
> > Validator.java:134)
> > >
> > >     at org.jboss.weld.bootstrap.Validator.validateRIBean(
> > Validator.java:155)
> > >
> > >     at org.jboss.weld.bootstrap.Validator.validateBean(
> > Validator.java:518)
> > >
> > >     at
> > > org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(
> > ConcurrentValidator.java:68)
> > >
> > >     at
> > > org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(
> > ConcurrentValidator.java:66)
> > >
> > >     at
> > > org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(
> > IterativeWorkerTaskFactory.java:60)
> > >
> > >     at
> > > org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(
> > IterativeWorkerTaskFactory.java:53)
> > >
> > >     at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> > >
> > >
> > >
> > > --
> > > Sent from: http://wildfly-development.1055759.n5.nabble.com/
> > > _______________________________________________
> > > wildfly-dev mailing list
> > > wildfly-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > >
> >
> 

From jperkins at redhat.com  Tue May 29 10:16:57 2018
From: jperkins at redhat.com (James Perkins)
Date: Tue, 29 May 2018 07:16:57 -0700
Subject: [wildfly-dev] Upgade from jboss-as-7.1.1.Final to
	wildfly-9.0.2.Final
In-Reply-To: <1527578763182-0.post@n5.nabble.com>
References: <1527578763182-0.post@n5.nabble.com>
Message-ID: <CADGwLpiZ0Fmnq9-x7oAxum0utdYxAfa4e-Yf0_s_GdiEoVHwvQ@mail.gmail.com>

This list is for discussing the development of WildFly itself. Questions
like this would be better on the forums
https://developer.jboss.org/en/wildfly.

On Tue, May 29, 2018 at 12:26 AM, wildflyuser <elayaraja.s at gmail.com> wrote:

> For upgrade from jboss-as-7.1.1.Final to wildfly-9.0.2.Final, do we need to
> follow any steps, it will be helpful for us.
>
>
>
> --
> Sent from: http://wildfly-development.1055759.n5.nabble.com/
> _______________________________________________
> 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/20180529/0357b8fd/attachment.html 

From asoldano at redhat.com  Wed May 30 05:27:20 2018
From: asoldano at redhat.com (Alessio Soldano)
Date: Wed, 30 May 2018 11:27:20 +0200
Subject: [wildfly-dev] How to set an authorized identity to EltyronSecurity
	Context
Message-ID: <CAKQecn8Dgvu+fA3HBTb4qpM2fqWJKQPDKtkH7fJsEbw09yxu3w@mail.gmail.com>

As suggested by Darran, I'm forwarding the message below to the list on
behalf of Jim.
The classes Jim is referring to are at
https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security


---------- Forwarded message ----------
From: Jim Ma <ema at redhat.com>
Date: Wed, May 30, 2018 at 9:03 AM
Subject: Set an authorized identity to EltyronSecurity Context
To: Darran Lofthouse <darran.lofthouse at redhat.com>
Cc: Alessio Soldano <asoldano at redhat.com>


Hi Darran,

We are helping look at a customer issue which requires propagate the
authenticated subject from webservice subsystem to

ejb subystem. With old security domain , we can do this with creating a
subject :

    @Override
    public void pushSubjectContext(final Subject subject, final Principal
principal, final Object credential) {
        AccessController.doPrivileged(new PrivilegedAction<Void>() {

            public Void run() {
                SecurityContext securityContext =
SecurityContextAssociation.getSecurityContext();
                if (securityContext == null) {
                    securityContext = createSecurityContext(getSecur
ityDomain());
setSecurityContextOnAssociation(securityContext);
                }
securityContext.getUtil().createSubjectInfo(principal, credential, subject);
                return null;
            }
        });
    }


After Elytron,  what is the equivalent thing to do this  then ejb can
retrieve this security without check this twice ?

Thanks,

Jim




-- 

Alessio Soldano

Associate Manager

Red Hat

<https://www.redhat.com>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180530/888ab513/attachment-0001.html 

From asoldano at redhat.com  Wed May 30 05:28:07 2018
From: asoldano at redhat.com (Alessio Soldano)
Date: Wed, 30 May 2018 11:28:07 +0200
Subject: [wildfly-dev] How to set an authorized identity to
	EltyronSecurity Context
In-Reply-To: <CAKQecn8Dgvu+fA3HBTb4qpM2fqWJKQPDKtkH7fJsEbw09yxu3w@mail.gmail.com>
References: <CAKQecn8Dgvu+fA3HBTb4qpM2fqWJKQPDKtkH7fJsEbw09yxu3w@mail.gmail.com>
Message-ID: <CAKQecn8Ok-aUmhkc93rqmFEtLQcc3dVLOU3V6o-ZvqAt7hnLGg@mail.gmail.com>

The tracking JIRA is https://issues.jboss.org/browse/WFLY-10480

On Wed, May 30, 2018 at 11:27 AM, Alessio Soldano <asoldano at redhat.com>
wrote:

> As suggested by Darran, I'm forwarding the message below to the list on
> behalf of Jim.
> The classes Jim is referring to are at https://github.com/wildfly/
> wildfly/tree/master/webservices/server-integration/src/main/java/org/
> jboss/as/webservices/security
>
>
> ---------- Forwarded message ----------
> From: Jim Ma <ema at redhat.com>
> Date: Wed, May 30, 2018 at 9:03 AM
> Subject: Set an authorized identity to EltyronSecurity Context
> To: Darran Lofthouse <darran.lofthouse at redhat.com>
> Cc: Alessio Soldano <asoldano at redhat.com>
>
>
> Hi Darran,
>
> We are helping look at a customer issue which requires propagate the
> authenticated subject from webservice subsystem to
>
> ejb subystem. With old security domain , we can do this with creating a
> subject :
>
>     @Override
>     public void pushSubjectContext(final Subject subject, final Principal
> principal, final Object credential) {
>         AccessController.doPrivileged(new PrivilegedAction<Void>() {
>
>             public Void run() {
>                 SecurityContext securityContext =
> SecurityContextAssociation.getSecurityContext();
>                 if (securityContext == null) {
>                     securityContext = createSecurityContext(getSecur
> ityDomain());
> setSecurityContextOnAssociation(securityContext);
>                 }
> securityContext.getUtil().createSubjectInfo(principal, credential,
> subject);
>                 return null;
>             }
>         });
>     }
>
>
> After Elytron,  what is the equivalent thing to do this  then ejb can
> retrieve this security without check this twice ?
>
> Thanks,
>
> Jim
>
>
>
>
> --
>
> Alessio Soldano
>
> Associate Manager
>
> Red Hat
>
> <https://www.redhat.com>
> <https://red.ht/sig>
>



-- 

Alessio Soldano

Associate Manager

Red Hat

<https://www.redhat.com>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180530/c06cce53/attachment.html 

From rsvoboda at redhat.com  Wed May 30 08:45:04 2018
From: rsvoboda at redhat.com (Rostislav Svoboda)
Date: Wed, 30 May 2018 14:45:04 +0200
Subject: [wildfly-dev] Pretty Print / VDX tests move into WildFly TS
Message-ID: <CACa2xU8LYF99SZdDcP0HB-0K3yf63WUpRRrQJ-mApaTcCKuXBw@mail.gmail.com>

Hi.

I would like to move existing tests for Pretty Print / VDX (introduced in
WF11 / EAP 7.1) into WildFly testsuite.

Testsuite runs with standalone and domain, structure is similar to WF TS (
org.wildfly.test.integration.vdx package, depends on jboss-parent, uses
JUnit, ARQ)
Current location is https://github.com/jboss-eap-qe/vdx-wildfly-testsuite

Tests are stable, TS is running around 3 minutes, it uses Creaper from
wildfly-extras (https://github.com/wildfly-extras/creaper). Creaper is used
for offline transformations of the config xml files -
https://github.com/jboss-eap-qe/vdx-wildfly-testsuite/tree/master/src/test/resources/org/wildfly/test/integration/vdx/transformations

I plan to put these tests under
https://github.com/wildfly/wildfly/tree/master/testsuite/integration as a
new module.

I would like to start with this effort next week, please let me know if you
have concerns about this move.

Thank you.
Rostislav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180530/45fc12a9/attachment.html 

From darran.lofthouse at redhat.com  Wed May 30 09:47:09 2018
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Wed, 30 May 2018 14:47:09 +0100
Subject: [wildfly-dev] How to set an authorized identity to
	EltyronSecurity Context
In-Reply-To: <CAKQecn8Dgvu+fA3HBTb4qpM2fqWJKQPDKtkH7fJsEbw09yxu3w@mail.gmail.com>
References: <CAKQecn8Dgvu+fA3HBTb4qpM2fqWJKQPDKtkH7fJsEbw09yxu3w@mail.gmail.com>
Message-ID: <CAMxVf4M=5fihM_2Z9XgC4M+b-72ensNfTyxf_7o=r=mvQivrmQ@mail.gmail.com>

I am currently gathering together some information regarding how the JCA
subsystem handles the requirement of populating a Subject for propagation
into a resource adapter, however there is a general question about what is
attempting to be achieved here.

Once an EJB is secured using WildFly Elytron the associated identity is not
accessed as a Subject instead it is accessed a SecurityIdentity the current
SecurityIdentity can always be retrieved by calling the current
SecurityDomain: -

http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrent--
http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrentSecurityIdentity--

The SecurityIdentity has some similarity with the Subject in that amongst
other things it also contains a collection of public credentials and a
collection of private credentials: -

http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPublicCredentials--
http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPrivateCredentials--

So I think the very first question is has the SecurityIdentity been
correctly populated with any delegated credentials?  If not that is going
to be a pre-requisite for any follow on steps regardless.

Then secondly what is it that is making use of this identity?  Why can't it
be ported to make use of the Elytron authentication client APIs which
amongst other things provide support for delegation from the current
identity.

If we need to we can look at a conversion to a Subject but we are only
doing that where it is really required.

Regards,
Darran Lofthouse.


On Wed, 30 May 2018 at 10:27 Alessio Soldano <asoldano at redhat.com> wrote:

> As suggested by Darran, I'm forwarding the message below to the list on
> behalf of Jim.
> The classes Jim is referring to are at
> https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security
>
>
> ---------- Forwarded message ----------
> From: Jim Ma <ema at redhat.com>
> Date: Wed, May 30, 2018 at 9:03 AM
> Subject: Set an authorized identity to EltyronSecurity Context
> To: Darran Lofthouse <darran.lofthouse at redhat.com>
> Cc: Alessio Soldano <asoldano at redhat.com>
>
>
> Hi Darran,
>
> We are helping look at a customer issue which requires propagate the
> authenticated subject from webservice subsystem to
>
> ejb subystem. With old security domain , we can do this with creating a
> subject :
>
>     @Override
>     public void pushSubjectContext(final Subject subject, final Principal
> principal, final Object credential) {
>         AccessController.doPrivileged(new PrivilegedAction<Void>() {
>
>             public Void run() {
>                 SecurityContext securityContext =
> SecurityContextAssociation.getSecurityContext();
>                 if (securityContext == null) {
>                     securityContext =
> createSecurityContext(getSecurityDomain());
> setSecurityContextOnAssociation(securityContext);
>                 }
> securityContext.getUtil().createSubjectInfo(principal, credential,
> subject);
>                 return null;
>             }
>         });
>     }
>
>
> After Elytron,  what is the equivalent thing to do this  then ejb can
> retrieve this security without check this twice ?
>
> Thanks,
>
> Jim
>
>
>
>
> --
>
> Alessio Soldano
>
> Associate Manager
>
> Red Hat
>
> <https://www.redhat.com>
> <https://red.ht/sig>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180530/9aacb903/attachment.html 

From sanne at hibernate.org  Wed May 30 11:20:53 2018
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 30 May 2018 16:20:53 +0100
Subject: [wildfly-dev] Provisioning tool to add a feature pack to an
	existing Wildfly instance
Message-ID: <CAFm4XO0NqWHthXG0PgVt3Xdtx175eNbLw33yKQOvmpOnyjcY8Q@mail.gmail.com>

we got some interesting feedback on the Hibernate forums today:
 - https://discourse.hibernate.org/t/org-hibernate-hibernate-orm-modules-no-longer-published/861/5

Is it possible to "add" a feature pack to WildFly with the old
provisioning tools?

Will it be possible with Galleon?

Thanks,
Sanne

From elayaraja.s at gmail.com  Wed May 30 22:08:42 2018
From: elayaraja.s at gmail.com (wildflyuser)
Date: Wed, 30 May 2018 19:08:42 -0700 (MST)
Subject: [wildfly-dev] wildfly-9.0.2.Final: Failed to start service
 jboss.deployment.unit."app.ear".WeldStartService:
In-Reply-To: <2027596710.37876760.1527588362609.JavaMail.zimbra@redhat.com>
References: <1527583885960-0.post@n5.nabble.com>
	<2027596710.37876760.1527588362609.JavaMail.zimbra@redhat.com>
Message-ID: <1527732522369-0.post@n5.nabble.com>


in my application i have replaced "org.glassfish.jersey"(version 2.8) to
"com.sun.jersey"(1.8) but still facing same error. 
Can i use both glassfish jersey and com.sun.jersey where ever applicable ?

ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001:
 Failed to start service jboss.deployment.unit."app.ear".WeldStartService:
 org.jboss.msc.service.StartException in service>
jboss.deployment.unit."app.ear".WeldStartService: Failed to start service
 at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:745)
 Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408:
 Unsatisfied dependencies for type ServiceLocator with qualifiers @Default
 at injection point [UnbackedAnnotatedField] @Inject private

org.glassfish.jersey.server.mvc.internal.ViewableMessageBodyWriter.serviceLocator 



--
Sent from: http://wildfly-development.1055759.n5.nabble.com/

From ema at redhat.com  Wed May 30 22:56:57 2018
From: ema at redhat.com (Jim Ma)
Date: Thu, 31 May 2018 10:56:57 +0800
Subject: [wildfly-dev] How to set an authorized identity to
	EltyronSecurity Context
In-Reply-To: <CAMxVf4M=5fihM_2Z9XgC4M+b-72ensNfTyxf_7o=r=mvQivrmQ@mail.gmail.com>
References: <CAKQecn8Dgvu+fA3HBTb4qpM2fqWJKQPDKtkH7fJsEbw09yxu3w@mail.gmail.com>
	<CAMxVf4M=5fihM_2Z9XgC4M+b-72ensNfTyxf_7o=r=mvQivrmQ@mail.gmail.com>
Message-ID: <91030cfe-1cdd-a7b9-6629-b4fee7cc6be9@redhat.com>

On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
> I am currently gathering together some information regarding how the 
> JCA subsystem handles the requirement of populating a Subject for 
> propagation into a resource adapter, however there is a general 
> question about what is attempting to be achieved here.
>
> Once an EJB is secured using WildFly Elytron the associated identity 
> is not accessed as a Subject instead it is accessed a SecurityIdentity 
> the current SecurityIdentity can always be retrieved by calling the 
> current SecurityDomain: -
>
> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrent--
> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrentSecurityIdentity--
>
> The SecurityIdentity has some similarity with the Subject in that 
> amongst other things it also contains a collection of public 
> credentials and a collection of private credentials: -
>
> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPublicCredentials--
> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPrivateCredentials--
>
> So I think the very first question is has the SecurityIdentity been 
> correctly populated with any delegated credentials?? If not that is 
> going to be a pre-requisite for any follow on steps regardless.
>
> Then secondly what is it that is making use of this identity?? Why 
> can't it be ported to make use of the Elytron authentication client 
> APIs which amongst other things provide support for delegation from 
> the current identity.
>
> If we need to we can look at a conversion to a Subject but we are only 
> doing that where it is really required.

 ? We don't have the SecurityIdentity populated, there is only principal 
and subject created by jbossws/CXF's saml validator.
 ? We need to convert the subject/principal to Elytron's 
SecurityIdentity or something else, then later on EJB subystem with Elytron
 ? security can retrieve this authenticated info without check it twice. 
So we'd like to know how can we convert a subject/principal
 ? to Elytron's SecurityIdentity and let Elytron know this is already 
authenticated and authorized.

Thanks,
Jim


>
> Regards,
> Darran Lofthouse.
>
>
> On Wed, 30 May 2018 at 10:27 Alessio Soldano <asoldano at redhat.com 
> <mailto:asoldano at redhat.com>> wrote:
>
>     As suggested by Darran, I'm forwarding the message below to the
>     list on behalf of Jim.
>     The classes Jim is referring to are at
>     https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security
>
>
>
>     ---------- Forwarded message ----------
>     From: *Jim Ma* <ema at redhat.com <mailto:ema at redhat.com>>
>     Date: Wed, May 30, 2018 at 9:03 AM
>     Subject: Set an authorized identity to EltyronSecurity Context
>     To: Darran Lofthouse <darran.lofthouse at redhat.com
>     <mailto:darran.lofthouse at redhat.com>>
>     Cc: Alessio Soldano <asoldano at redhat.com <mailto:asoldano at redhat.com>>
>
>
>     Hi Darran,
>
>     We are helping look at a customer issue which requires propagate
>     the authenticated subject from webservice subsystem to
>
>     ejb subystem. With old security domain , we can do this with
>     creating a subject :
>
>     ??? @Override
>     ??? public void pushSubjectContext(final Subject subject, final
>     Principal principal, final Object credential) {
>     ??????? AccessController.doPrivileged(new PrivilegedAction<Void>() {
>
>     ??????????? public Void run() {
>     ??????????????? SecurityContext securityContext =
>     SecurityContextAssociation.getSecurityContext();
>     ??????????????? if (securityContext == null) {
>     ??????????????????? securityContext =
>     createSecurityContext(getSecurityDomain());
>     setSecurityContextOnAssociation(securityContext);
>     ??????????????? }
>     securityContext.getUtil().createSubjectInfo(principal, credential,
>     subject);
>     ??????????????? return null;
>     ??????????? }
>     ??????? });
>     ??? }
>
>
>     After Elytron,? what is the equivalent thing to do this? then ejb
>     can retrieve this security without check this twice ?
>
>     Thanks,
>
>     Jim
>
>
>
>
>     -- 
>
>     Alessio Soldano
>
>     Associate Manager
>
>     Red Hat
>
>     <https://www.redhat.com>
>
>     <https://red.ht/sig>
>

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

From darran.lofthouse at redhat.com  Thu May 31 05:07:16 2018
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Thu, 31 May 2018 10:07:16 +0100
Subject: [wildfly-dev] How to set an authorized identity to
	EltyronSecurity Context
In-Reply-To: <91030cfe-1cdd-a7b9-6629-b4fee7cc6be9@redhat.com>
References: <CAKQecn8Dgvu+fA3HBTb4qpM2fqWJKQPDKtkH7fJsEbw09yxu3w@mail.gmail.com>
	<CAMxVf4M=5fihM_2Z9XgC4M+b-72ensNfTyxf_7o=r=mvQivrmQ@mail.gmail.com>
	<91030cfe-1cdd-a7b9-6629-b4fee7cc6be9@redhat.com>
Message-ID: <CAMxVf4OKnp0Wn3PX=GH39c21hj1W8=b1GDgANMj8EevBW1cn7g@mail.gmail.com>

It sounds to me then that the place to start is within the SAML validation,
this is effectively an authentication step so should be ported over to an
Elytron based authentication - the end result of the authentication would
then be the required SecurityIdentity to propagate from container to
container.


On Thu, 31 May 2018 at 03:57 Jim Ma <ema at redhat.com> wrote:

> On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
>
> I am currently gathering together some information regarding how the JCA
> subsystem handles the requirement of populating a Subject for propagation
> into a resource adapter, however there is a general question about what is
> attempting to be achieved here.
>
> Once an EJB is secured using WildFly Elytron the associated identity is
> not accessed as a Subject instead it is accessed a SecurityIdentity the
> current SecurityIdentity can always be retrieved by calling the current
> SecurityDomain: -
>
>
> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrent--
>
> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrentSecurityIdentity--
>
> The SecurityIdentity has some similarity with the Subject in that amongst
> other things it also contains a collection of public credentials and a
> collection of private credentials: -
>
>
> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPublicCredentials--
>
> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPrivateCredentials--
>
> So I think the very first question is has the SecurityIdentity been
> correctly populated with any delegated credentials?  If not that is going
> to be a pre-requisite for any follow on steps regardless.
>
> Then secondly what is it that is making use of this identity?  Why can't
> it be ported to make use of the Elytron authentication client APIs which
> amongst other things provide support for delegation from the current
> identity.
>
>
> If we need to we can look at a conversion to a Subject but we are only
> doing that where it is really required.
>
>
>   We don't have the SecurityIdentity populated, there is only principal
> and subject created by jbossws/CXF's saml validator.
>   We need to convert the subject/principal to Elytron's SecurityIdentity
> or something else, then later on EJB subystem with Elytron
>   security can retrieve this authenticated info without check it twice. So
> we'd like to know how can we convert a subject/principal
>   to Elytron's SecurityIdentity and let Elytron know this is already
> authenticated and authorized.
>
> Thanks,
> Jim
>
>
>
> Regards,
> Darran Lofthouse.
>
>
> On Wed, 30 May 2018 at 10:27 Alessio Soldano <asoldano at redhat.com> wrote:
>
>> As suggested by Darran, I'm forwarding the message below to the list on
>> behalf of Jim.
>> The classes Jim is referring to are at
>> https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security
>>
>>
>> ---------- Forwarded message ----------
>> From: Jim Ma <ema at redhat.com>
>> Date: Wed, May 30, 2018 at 9:03 AM
>> Subject: Set an authorized identity to EltyronSecurity Context
>> To: Darran Lofthouse <darran.lofthouse at redhat.com>
>> Cc: Alessio Soldano <asoldano at redhat.com>
>>
>>
>> Hi Darran,
>>
>> We are helping look at a customer issue which requires propagate the
>> authenticated subject from webservice subsystem to
>>
>> ejb subystem. With old security domain , we can do this with creating a
>> subject :
>>
>>     @Override
>>     public void pushSubjectContext(final Subject subject, final Principal
>> principal, final Object credential) {
>>         AccessController.doPrivileged(new PrivilegedAction<Void>() {
>>
>>             public Void run() {
>>                 SecurityContext securityContext =
>> SecurityContextAssociation.getSecurityContext();
>>                 if (securityContext == null) {
>>                     securityContext =
>> createSecurityContext(getSecurityDomain());
>> setSecurityContextOnAssociation(securityContext);
>>                 }
>> securityContext.getUtil().createSubjectInfo(principal, credential,
>> subject);
>>                 return null;
>>             }
>>         });
>>     }
>>
>>
>> After Elytron,  what is the equivalent thing to do this  then ejb can
>> retrieve this security without check this twice ?
>>
>> Thanks,
>>
>> Jim
>>
>>
>>
>>
>> --
>>
>> Alessio Soldano
>>
>> Associate Manager
>>
>> Red Hat
>>
>> <https://www.redhat.com>
>> <https://red.ht/sig>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180531/b48cc423/attachment-0001.html 

From ema at redhat.com  Thu May 31 05:34:41 2018
From: ema at redhat.com (Jim Ma)
Date: Thu, 31 May 2018 17:34:41 +0800
Subject: [wildfly-dev] How to set an authorized identity to
	EltyronSecurity Context
In-Reply-To: <CAMxVf4OKnp0Wn3PX=GH39c21hj1W8=b1GDgANMj8EevBW1cn7g@mail.gmail.com>
References: <CAKQecn8Dgvu+fA3HBTb4qpM2fqWJKQPDKtkH7fJsEbw09yxu3w@mail.gmail.com>
	<CAMxVf4M=5fihM_2Z9XgC4M+b-72ensNfTyxf_7o=r=mvQivrmQ@mail.gmail.com>
	<91030cfe-1cdd-a7b9-6629-b4fee7cc6be9@redhat.com>
	<CAMxVf4OKnp0Wn3PX=GH39c21hj1W8=b1GDgANMj8EevBW1cn7g@mail.gmail.com>
Message-ID: <bcbd8f9e-bae3-927c-5232-7dc11820462d@redhat.com>

The saml validation is now Apache CXF's SAML functionality. We can't 
port the CXF's security to rely on
our Elytron.

On 05/31/2018 05:07 PM, Darran Lofthouse wrote:
> It sounds to me then that the place to start is within the SAML 
> validation, this is effectively an authentication step so should be 
> ported over to an Elytron based authentication - the end result of the 
> authentication would then be the required SecurityIdentity to 
> propagate from container to container.
>
>
> On Thu, 31 May 2018 at 03:57 Jim Ma <ema at redhat.com 
> <mailto:ema at redhat.com>> wrote:
>
>     On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
>>     I am currently gathering together some information regarding how
>>     the JCA subsystem handles the requirement of populating a Subject
>>     for propagation into a resource adapter, however there is a
>>     general question about what is attempting to be achieved here.
>>
>>     Once an EJB is secured using WildFly Elytron the associated
>>     identity is not accessed as a Subject instead it is accessed a
>>     SecurityIdentity the current SecurityIdentity can always be
>>     retrieved by calling the current SecurityDomain: -
>>
>>     http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrent--
>>     http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrentSecurityIdentity--
>>
>>     The SecurityIdentity has some similarity with the Subject in that
>>     amongst other things it also contains a collection of public
>>     credentials and a collection of private credentials: -
>>
>>     http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPublicCredentials--
>>     http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPrivateCredentials--
>>
>>     So I think the very first question is has the SecurityIdentity
>>     been correctly populated with any delegated credentials?? If not
>>     that is going to be a pre-requisite for any follow on steps
>>     regardless.
>>
>>     Then secondly what is it that is making use of this identity??
>>     Why can't it be ported to make use of the Elytron authentication
>>     client APIs which amongst other things provide support for
>>     delegation from the current identity.
>>
>>     If we need to we can look at a conversion to a Subject but we are
>>     only doing that where it is really required.
>
>     ? We don't have the SecurityIdentity populated, there is only
>     principal and subject created by jbossws/CXF's saml validator.
>     ? We need to convert the subject/principal to Elytron's
>     SecurityIdentity or something else, then later on EJB subystem
>     with Elytron
>     ? security can retrieve this authenticated info without check it
>     twice. So we'd like to know how can we convert a subject/principal
>     ? to Elytron's SecurityIdentity and let Elytron know this is
>     already authenticated and authorized.
>
>     Thanks,
>     Jim
>
>
>>
>>     Regards,
>>     Darran Lofthouse.
>>
>>
>>     On Wed, 30 May 2018 at 10:27 Alessio Soldano <asoldano at redhat.com
>>     <mailto:asoldano at redhat.com>> wrote:
>>
>>         As suggested by Darran, I'm forwarding the message below to
>>         the list on behalf of Jim.
>>         The classes Jim is referring to are at
>>         https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security
>>
>>
>>
>>         ---------- Forwarded message ----------
>>         From: *Jim Ma* <ema at redhat.com <mailto:ema at redhat.com>>
>>         Date: Wed, May 30, 2018 at 9:03 AM
>>         Subject: Set an authorized identity to EltyronSecurity Context
>>         To: Darran Lofthouse <darran.lofthouse at redhat.com
>>         <mailto:darran.lofthouse at redhat.com>>
>>         Cc: Alessio Soldano <asoldano at redhat.com
>>         <mailto:asoldano at redhat.com>>
>>
>>
>>         Hi Darran,
>>
>>         We are helping look at a customer issue which requires
>>         propagate the authenticated subject from webservice subsystem to
>>
>>         ejb subystem. With old security domain , we can do this with
>>         creating a subject :
>>
>>         ??? @Override
>>         ??? public void pushSubjectContext(final Subject subject,
>>         final Principal principal, final Object credential) {
>>         ??????? AccessController.doPrivileged(new
>>         PrivilegedAction<Void>() {
>>
>>         ??????????? public Void run() {
>>         ??????????????? SecurityContext securityContext =
>>         SecurityContextAssociation.getSecurityContext();
>>         ??????????????? if (securityContext == null) {
>>         ??????????????????? securityContext =
>>         createSecurityContext(getSecurityDomain());
>>         setSecurityContextOnAssociation(securityContext);
>>         ??????????????? }
>>         securityContext.getUtil().createSubjectInfo(principal,
>>         credential, subject);
>>         ??????????????? return null;
>>         ??????????? }
>>         ??????? });
>>         ??? }
>>
>>
>>         After Elytron,? what is the equivalent thing to do this? then
>>         ejb can retrieve this security without check this twice ?
>>
>>         Thanks,
>>
>>         Jim
>>
>>
>>
>>
>>         -- 
>>
>>         Alessio Soldano
>>
>>         Associate Manager
>>
>>         Red Hat
>>
>>         <https://www.redhat.com>
>>
>>         <https://red.ht/sig>
>>
>

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

From darran.lofthouse at redhat.com  Thu May 31 05:37:00 2018
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Thu, 31 May 2018 10:37:00 +0100
Subject: [wildfly-dev] How to set an authorized identity to
	EltyronSecurity Context
In-Reply-To: <bcbd8f9e-bae3-927c-5232-7dc11820462d@redhat.com>
References: <CAKQecn8Dgvu+fA3HBTb4qpM2fqWJKQPDKtkH7fJsEbw09yxu3w@mail.gmail.com>
	<CAMxVf4M=5fihM_2Z9XgC4M+b-72ensNfTyxf_7o=r=mvQivrmQ@mail.gmail.com>
	<91030cfe-1cdd-a7b9-6629-b4fee7cc6be9@redhat.com>
	<CAMxVf4OKnp0Wn3PX=GH39c21hj1W8=b1GDgANMj8EevBW1cn7g@mail.gmail.com>
	<bcbd8f9e-bae3-927c-5232-7dc11820462d@redhat.com>
Message-ID: <CAMxVf4OjZQwqND3Q0rbMtORuatdMS1sR057JZ3_Y4D2Opjo=9A@mail.gmail.com>

So the validation is within Apache CXF - is there an end result to this
validation where you have access to everything you need where we could
perform some additional steps?


On Thu, 31 May 2018 at 10:34 Jim Ma <ema at redhat.com> wrote:

> The saml validation is now Apache CXF's SAML functionality. We can't port
> the CXF's security to rely on
> our Elytron.
>
> On 05/31/2018 05:07 PM, Darran Lofthouse wrote:
>
> It sounds to me then that the place to start is within the SAML
> validation, this is effectively an authentication step so should be ported
> over to an Elytron based authentication - the end result of the
> authentication would then be the required SecurityIdentity to propagate
> from container to container.
>
>
> On Thu, 31 May 2018 at 03:57 Jim Ma <ema at redhat.com> wrote:
>
>> On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
>>
>> I am currently gathering together some information regarding how the JCA
>> subsystem handles the requirement of populating a Subject for propagation
>> into a resource adapter, however there is a general question about what is
>> attempting to be achieved here.
>>
>> Once an EJB is secured using WildFly Elytron the associated identity is
>> not accessed as a Subject instead it is accessed a SecurityIdentity the
>> current SecurityIdentity can always be retrieved by calling the current
>> SecurityDomain: -
>>
>>
>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrent--
>>
>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrentSecurityIdentity--
>>
>> The SecurityIdentity has some similarity with the Subject in that amongst
>> other things it also contains a collection of public credentials and a
>> collection of private credentials: -
>>
>>
>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPublicCredentials--
>>
>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPrivateCredentials--
>>
>> So I think the very first question is has the SecurityIdentity been
>> correctly populated with any delegated credentials?  If not that is going
>> to be a pre-requisite for any follow on steps regardless.
>>
>> Then secondly what is it that is making use of this identity?  Why can't
>> it be ported to make use of the Elytron authentication client APIs which
>> amongst other things provide support for delegation from the current
>> identity.
>>
>>
>> If we need to we can look at a conversion to a Subject but we are only
>> doing that where it is really required.
>>
>>
>>   We don't have the SecurityIdentity populated, there is only principal
>> and subject created by jbossws/CXF's saml validator.
>>   We need to convert the subject/principal to Elytron's SecurityIdentity
>> or something else, then later on EJB subystem with Elytron
>>   security can retrieve this authenticated info without check it twice.
>> So we'd like to know how can we convert a subject/principal
>>   to Elytron's SecurityIdentity and let Elytron know this is already
>> authenticated and authorized.
>>
>> Thanks,
>> Jim
>>
>>
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On Wed, 30 May 2018 at 10:27 Alessio Soldano <asoldano at redhat.com> wrote:
>>
>>> As suggested by Darran, I'm forwarding the message below to the list on
>>> behalf of Jim.
>>> The classes Jim is referring to are at
>>> https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Jim Ma <ema at redhat.com>
>>> Date: Wed, May 30, 2018 at 9:03 AM
>>> Subject: Set an authorized identity to EltyronSecurity Context
>>> To: Darran Lofthouse <darran.lofthouse at redhat.com>
>>> Cc: Alessio Soldano <asoldano at redhat.com>
>>>
>>>
>>> Hi Darran,
>>>
>>> We are helping look at a customer issue which requires propagate the
>>> authenticated subject from webservice subsystem to
>>>
>>> ejb subystem. With old security domain , we can do this with creating a
>>> subject :
>>>
>>>     @Override
>>>     public void pushSubjectContext(final Subject subject, final
>>> Principal principal, final Object credential) {
>>>         AccessController.doPrivileged(new PrivilegedAction<Void>() {
>>>
>>>             public Void run() {
>>>                 SecurityContext securityContext =
>>> SecurityContextAssociation.getSecurityContext();
>>>                 if (securityContext == null) {
>>>                     securityContext =
>>> createSecurityContext(getSecurityDomain());
>>> setSecurityContextOnAssociation(securityContext);
>>>                 }
>>> securityContext.getUtil().createSubjectInfo(principal, credential,
>>> subject);
>>>                 return null;
>>>             }
>>>         });
>>>     }
>>>
>>>
>>> After Elytron,  what is the equivalent thing to do this  then ejb can
>>> retrieve this security without check this twice ?
>>>
>>> Thanks,
>>>
>>> Jim
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Alessio Soldano
>>>
>>> Associate Manager
>>>
>>> Red Hat
>>>
>>> <https://www.redhat.com>
>>> <https://red.ht/sig>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180531/e034eef1/attachment-0001.html 

From ema at redhat.com  Thu May 31 05:53:52 2018
From: ema at redhat.com (Jim Ma)
Date: Thu, 31 May 2018 17:53:52 +0800
Subject: [wildfly-dev] How to set an authorized identity to
	EltyronSecurity Context
In-Reply-To: <CAMxVf4OjZQwqND3Q0rbMtORuatdMS1sR057JZ3_Y4D2Opjo=9A@mail.gmail.com>
References: <CAKQecn8Dgvu+fA3HBTb4qpM2fqWJKQPDKtkH7fJsEbw09yxu3w@mail.gmail.com>
	<CAMxVf4M=5fihM_2Z9XgC4M+b-72ensNfTyxf_7o=r=mvQivrmQ@mail.gmail.com>
	<91030cfe-1cdd-a7b9-6629-b4fee7cc6be9@redhat.com>
	<CAMxVf4OKnp0Wn3PX=GH39c21hj1W8=b1GDgANMj8EevBW1cn7g@mail.gmail.com>
	<bcbd8f9e-bae3-927c-5232-7dc11820462d@redhat.com>
	<CAMxVf4OjZQwqND3Q0rbMtORuatdMS1sR057JZ3_Y4D2Opjo=9A@mail.gmail.com>
Message-ID: <7fe0d553-2190-fa48-6728-41240497cb0c@redhat.com>

On 05/31/2018 05:37 PM, Darran Lofthouse wrote:
> So the validation is within Apache CXF - is there an end result to 
> this validation where you have access to everything you need where we 
> could perform some additional steps?
>

 ?After Apache CXF validation, we can get a LoginContext from CXF's 
exchange message : 
https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/security/LoginSecurityContext.java
 ?Can we do something to convert it to an Elytron authenticated identity ?
 ?Or we have to hook/replace something with Elytron in CXF's validation 
to make this work ?

>
> On Thu, 31 May 2018 at 10:34 Jim Ma <ema at redhat.com 
> <mailto:ema at redhat.com>> wrote:
>
>     The saml validation is now Apache CXF's SAML functionality. We
>     can't port the CXF's security to rely on
>     our Elytron.
>
>     On 05/31/2018 05:07 PM, Darran Lofthouse wrote:
>>     It sounds to me then that the place to start is within the SAML
>>     validation, this is effectively an authentication step so should
>>     be ported over to an Elytron based authentication - the end
>>     result of the authentication would then be the required
>>     SecurityIdentity to propagate from container to container.
>>
>>
>>     On Thu, 31 May 2018 at 03:57 Jim Ma <ema at redhat.com
>>     <mailto:ema at redhat.com>> wrote:
>>
>>         On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
>>>         I am currently gathering together some information regarding
>>>         how the JCA subsystem handles the requirement of populating
>>>         a Subject for propagation into a resource adapter, however
>>>         there is a general question about what is attempting to be
>>>         achieved here.
>>>
>>>         Once an EJB is secured using WildFly Elytron the associated
>>>         identity is not accessed as a Subject instead it is accessed
>>>         a SecurityIdentity the current SecurityIdentity can always
>>>         be retrieved by calling the current SecurityDomain: -
>>>
>>>         http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrent--
>>>         http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrentSecurityIdentity--
>>>
>>>         The SecurityIdentity has some similarity with the Subject in
>>>         that amongst other things it also contains a collection of
>>>         public credentials and a collection of private credentials: -
>>>
>>>         http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPublicCredentials--
>>>         http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPrivateCredentials--
>>>
>>>         So I think the very first question is has the
>>>         SecurityIdentity been correctly populated with any delegated
>>>         credentials?? If not that is going to be a pre-requisite for
>>>         any follow on steps regardless.
>>>
>>>         Then secondly what is it that is making use of this
>>>         identity?? Why can't it be ported to make use of the Elytron
>>>         authentication client APIs which amongst other things
>>>         provide support for delegation from the current identity.
>>>
>>>         If we need to we can look at a conversion to a Subject but
>>>         we are only doing that where it is really required.
>>
>>         ? We don't have the SecurityIdentity populated, there is only
>>         principal and subject created by jbossws/CXF's saml validator.
>>         ? We need to convert the subject/principal to Elytron's
>>         SecurityIdentity or something else, then later on EJB
>>         subystem with Elytron
>>         ? security can retrieve this authenticated info without check
>>         it twice. So we'd like to know how can we convert a
>>         subject/principal
>>         ? to Elytron's SecurityIdentity and let Elytron know this is
>>         already authenticated and authorized.
>>
>>         Thanks,
>>         Jim
>>
>>
>>>
>>>         Regards,
>>>         Darran Lofthouse.
>>>
>>>
>>>         On Wed, 30 May 2018 at 10:27 Alessio Soldano
>>>         <asoldano at redhat.com <mailto:asoldano at redhat.com>> wrote:
>>>
>>>             As suggested by Darran, I'm forwarding the message below
>>>             to the list on behalf of Jim.
>>>             The classes Jim is referring to are at
>>>             https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security
>>>
>>>
>>>
>>>             ---------- Forwarded message ----------
>>>             From: *Jim Ma* <ema at redhat.com <mailto:ema at redhat.com>>
>>>             Date: Wed, May 30, 2018 at 9:03 AM
>>>             Subject: Set an authorized identity to EltyronSecurity
>>>             Context
>>>             To: Darran Lofthouse <darran.lofthouse at redhat.com
>>>             <mailto:darran.lofthouse at redhat.com>>
>>>             Cc: Alessio Soldano <asoldano at redhat.com
>>>             <mailto:asoldano at redhat.com>>
>>>
>>>
>>>             Hi Darran,
>>>
>>>             We are helping look at a customer issue which requires
>>>             propagate the authenticated subject from webservice
>>>             subsystem to
>>>
>>>             ejb subystem. With old security domain , we can do this
>>>             with creating a subject :
>>>
>>>             ??? @Override
>>>             ??? public void pushSubjectContext(final Subject
>>>             subject, final Principal principal, final Object
>>>             credential) {
>>>             AccessController.doPrivileged(new PrivilegedAction<Void>() {
>>>
>>>             ??????????? public Void run() {
>>>             ??????????????? SecurityContext securityContext =
>>>             SecurityContextAssociation.getSecurityContext();
>>>             ??????????????? if (securityContext == null) {
>>>             ??????????????????? securityContext =
>>>             createSecurityContext(getSecurityDomain());
>>>             setSecurityContextOnAssociation(securityContext);
>>>             ??????????????? }
>>>             securityContext.getUtil().createSubjectInfo(principal,
>>>             credential, subject);
>>>             ??????????????? return null;
>>>             ??????????? }
>>>             ??????? });
>>>             ??? }
>>>
>>>
>>>             After Elytron,? what is the equivalent thing to do this?
>>>             then ejb can retrieve this security without check this
>>>             twice ?
>>>
>>>             Thanks,
>>>
>>>             Jim
>>>
>>>
>>>
>>>
>>>             -- 
>>>
>>>             Alessio Soldano
>>>
>>>             Associate Manager
>>>
>>>             Red Hat
>>>
>>>             <https://www.redhat.com>
>>>
>>>             <https://red.ht/sig>
>>>
>>
>

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

From darran.lofthouse at redhat.com  Thu May 31 06:03:17 2018
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Thu, 31 May 2018 11:03:17 +0100
Subject: [wildfly-dev] How to set an authorized identity to
	EltyronSecurity Context
In-Reply-To: <7fe0d553-2190-fa48-6728-41240497cb0c@redhat.com>
References: <CAKQecn8Dgvu+fA3HBTb4qpM2fqWJKQPDKtkH7fJsEbw09yxu3w@mail.gmail.com>
	<CAMxVf4M=5fihM_2Z9XgC4M+b-72ensNfTyxf_7o=r=mvQivrmQ@mail.gmail.com>
	<91030cfe-1cdd-a7b9-6629-b4fee7cc6be9@redhat.com>
	<CAMxVf4OKnp0Wn3PX=GH39c21hj1W8=b1GDgANMj8EevBW1cn7g@mail.gmail.com>
	<bcbd8f9e-bae3-927c-5232-7dc11820462d@redhat.com>
	<CAMxVf4OjZQwqND3Q0rbMtORuatdMS1sR057JZ3_Y4D2Opjo=9A@mail.gmail.com>
	<7fe0d553-2190-fa48-6728-41240497cb0c@redhat.com>
Message-ID: <CAMxVf4MpQey5T+7KrQGzr=w2ve=4Y7d83yJTgJUP__Whjzk79Q@mail.gmail.com>

Just added Pedro in CC so see if he has any suggestions - this is sounding
similar to the problems he would have needed to handle when he added
support for KeyCloak integration using the Elytron APIs.

Although the reported problem we are working on is in the context of access
to the token it does currently sound that there is a missing pre-requisite
step of tying the authentication to Elytron to we can populate a
SecurityIdentity.  But this does not sound like the first time we have
needed to approach this.

Regards,
Darran Lofthouse.


On Thu, 31 May 2018 at 10:54 Jim Ma <ema at redhat.com> wrote:

> On 05/31/2018 05:37 PM, Darran Lofthouse wrote:
>
> So the validation is within Apache CXF - is there an end result to this
> validation where you have access to everything you need where we could
> perform some additional steps?
>
>
>  After Apache CXF validation, we can get a LoginContext from CXF's
> exchange message :
> https://github.com/apache/cxf/blob/master/core/src/main/java/org/apache/cxf/security/LoginSecurityContext.java
>  Can we do something to convert it to an Elytron authenticated identity ?
>  Or we have to hook/replace something with Elytron in CXF's validation to
> make this work ?
>
>
>
> On Thu, 31 May 2018 at 10:34 Jim Ma <ema at redhat.com> wrote:
>
>> The saml validation is now Apache CXF's SAML functionality. We can't port
>> the CXF's security to rely on
>> our Elytron.
>>
>> On 05/31/2018 05:07 PM, Darran Lofthouse wrote:
>>
>> It sounds to me then that the place to start is within the SAML
>> validation, this is effectively an authentication step so should be ported
>> over to an Elytron based authentication - the end result of the
>> authentication would then be the required SecurityIdentity to propagate
>> from container to container.
>>
>>
>> On Thu, 31 May 2018 at 03:57 Jim Ma <ema at redhat.com> wrote:
>>
>>> On 05/30/2018 09:47 PM, Darran Lofthouse wrote:
>>>
>>> I am currently gathering together some information regarding how the JCA
>>> subsystem handles the requirement of populating a Subject for propagation
>>> into a resource adapter, however there is a general question about what is
>>> attempting to be achieved here.
>>>
>>> Once an EJB is secured using WildFly Elytron the associated identity is
>>> not accessed as a Subject instead it is accessed a SecurityIdentity the
>>> current SecurityIdentity can always be retrieved by calling the current
>>> SecurityDomain: -
>>>
>>>
>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrent--
>>>
>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityDomain.html#getCurrentSecurityIdentity--
>>>
>>> The SecurityIdentity has some similarity with the Subject in that
>>> amongst other things it also contains a collection of public credentials
>>> and a collection of private credentials: -
>>>
>>>
>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPublicCredentials--
>>>
>>> http://wildfly-security.github.io/wildfly-elytron/1.3.x/api-javadoc/org/wildfly/security/auth/server/SecurityIdentity.html#getPrivateCredentials--
>>>
>>> So I think the very first question is has the SecurityIdentity been
>>> correctly populated with any delegated credentials?  If not that is going
>>> to be a pre-requisite for any follow on steps regardless.
>>>
>>> Then secondly what is it that is making use of this identity?  Why can't
>>> it be ported to make use of the Elytron authentication client APIs which
>>> amongst other things provide support for delegation from the current
>>> identity.
>>>
>>>
>>> If we need to we can look at a conversion to a Subject but we are only
>>> doing that where it is really required.
>>>
>>>
>>>   We don't have the SecurityIdentity populated, there is only principal
>>> and subject created by jbossws/CXF's saml validator.
>>>   We need to convert the subject/principal to Elytron's SecurityIdentity
>>> or something else, then later on EJB subystem with Elytron
>>>   security can retrieve this authenticated info without check it twice.
>>> So we'd like to know how can we convert a subject/principal
>>>   to Elytron's SecurityIdentity and let Elytron know this is already
>>> authenticated and authorized.
>>>
>>> Thanks,
>>> Jim
>>>
>>>
>>>
>>> Regards,
>>> Darran Lofthouse.
>>>
>>>
>>> On Wed, 30 May 2018 at 10:27 Alessio Soldano <asoldano at redhat.com>
>>> wrote:
>>>
>>>> As suggested by Darran, I'm forwarding the message below to the list on
>>>> behalf of Jim.
>>>> The classes Jim is referring to are at
>>>> https://github.com/wildfly/wildfly/tree/master/webservices/server-integration/src/main/java/org/jboss/as/webservices/security
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Jim Ma <ema at redhat.com>
>>>> Date: Wed, May 30, 2018 at 9:03 AM
>>>> Subject: Set an authorized identity to EltyronSecurity Context
>>>> To: Darran Lofthouse <darran.lofthouse at redhat.com>
>>>> Cc: Alessio Soldano <asoldano at redhat.com>
>>>>
>>>>
>>>> Hi Darran,
>>>>
>>>> We are helping look at a customer issue which requires propagate the
>>>> authenticated subject from webservice subsystem to
>>>>
>>>> ejb subystem. With old security domain , we can do this with creating a
>>>> subject :
>>>>
>>>>     @Override
>>>>     public void pushSubjectContext(final Subject subject, final
>>>> Principal principal, final Object credential) {
>>>>         AccessController.doPrivileged(new PrivilegedAction<Void>() {
>>>>
>>>>             public Void run() {
>>>>                 SecurityContext securityContext =
>>>> SecurityContextAssociation.getSecurityContext();
>>>>                 if (securityContext == null) {
>>>>                     securityContext =
>>>> createSecurityContext(getSecurityDomain());
>>>> setSecurityContextOnAssociation(securityContext);
>>>>                 }
>>>> securityContext.getUtil().createSubjectInfo(principal, credential,
>>>> subject);
>>>>                 return null;
>>>>             }
>>>>         });
>>>>     }
>>>>
>>>>
>>>> After Elytron,  what is the equivalent thing to do this  then ejb can
>>>> retrieve this security without check this twice ?
>>>>
>>>> Thanks,
>>>>
>>>> Jim
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Alessio Soldano
>>>>
>>>> Associate Manager
>>>>
>>>> Red Hat
>>>>
>>>> <https://www.redhat.com>
>>>> <https://red.ht/sig>
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180531/356808d0/attachment-0001.html 

From david.lloyd at redhat.com  Thu May 31 10:47:53 2018
From: david.lloyd at redhat.com (David Lloyd)
Date: Thu, 31 May 2018 09:47:53 -0500
Subject: [wildfly-dev] Action Required: Security Manager issues
Message-ID: <CANghgrRQsdTxe8tPpc5APZnfUV4EdNf2ho_oj+8veQcQ5pWObg@mail.gmail.com>

Now that WildFly 13 is released, I would like to ask that everyone
please take some time to prioritize and solve the security manager
related issues in their area.  These can be found using the query
below [1].  If the underlying issue is in an upstream project, please
add a "caused by" link to the project in question.

If you are not the right person to address a certain issue, then
please /cc the right person before you unwatch it to ensure that no
issues fall through the cracks.

It is my goal to have the security manager CI build [2] running
cleanly and integrated into PR processing before the WildFly 14
release.

Note that some SM problems don't appear as test failures.  I plan to
introduce a mechanism whereby all access check failures are logged and
we can review this log (perhaps automatically) on each test run.  This
however is going to be a future enhancement.

[1] https://issues.jboss.org/issues?jql=(assignee%20%3D%20currentUser()%20or%20watcher%20%3D%20currentUser())%20and%20status%20not%20in%20(resolved%2C%20closed)%20and%20labels%20%3D%20"security-manager"

[2] https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterSecurityManager

-- 
- DML

From david.lloyd at redhat.com  Thu May 31 10:49:27 2018
From: david.lloyd at redhat.com (David Lloyd)
Date: Thu, 31 May 2018 09:49:27 -0500
Subject: [wildfly-dev] Action Required: Security Manager issues
In-Reply-To: <CANghgrRQsdTxe8tPpc5APZnfUV4EdNf2ho_oj+8veQcQ5pWObg@mail.gmail.com>
References: <CANghgrRQsdTxe8tPpc5APZnfUV4EdNf2ho_oj+8veQcQ5pWObg@mail.gmail.com>
Message-ID: <CANghgrT3=FMdSiRJYLfaa3txjA8AYJ59sLiBzc8tTago0S5xMA@mail.gmail.com>

In case that link didn't render for you, you can use
https://red.ht/2LOk1GP instead.



On Thu, May 31, 2018 at 9:47 AM, David Lloyd <david.lloyd at redhat.com> wrote:
> Now that WildFly 13 is released, I would like to ask that everyone
> please take some time to prioritize and solve the security manager
> related issues in their area.  These can be found using the query
> below [1].  If the underlying issue is in an upstream project, please
> add a "caused by" link to the project in question.
>
> If you are not the right person to address a certain issue, then
> please /cc the right person before you unwatch it to ensure that no
> issues fall through the cracks.
>
> It is my goal to have the security manager CI build [2] running
> cleanly and integrated into PR processing before the WildFly 14
> release.
>
> Note that some SM problems don't appear as test failures.  I plan to
> introduce a mechanism whereby all access check failures are logged and
> we can review this log (perhaps automatically) on each test run.  This
> however is going to be a future enhancement.
>
> [1] https://issues.jboss.org/issues?jql=(assignee%20%3D%20currentUser()%20or%20watcher%20%3D%20currentUser())%20and%20status%20not%20in%20(resolved%2C%20closed)%20and%20labels%20%3D%20"security-manager"
>
> [2] https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterSecurityManager
>
> --
> - DML



-- 
- DML

From alexey.loubyansky at redhat.com  Thu May 31 11:19:58 2018
From: alexey.loubyansky at redhat.com (Alexey Loubyansky)
Date: Thu, 31 May 2018 17:19:58 +0200
Subject: [wildfly-dev] Provisioning tool to add a feature pack to an
 existing Wildfly instance
In-Reply-To: <CAFm4XO0NqWHthXG0PgVt3Xdtx175eNbLw33yKQOvmpOnyjcY8Q@mail.gmail.com>
References: <CAFm4XO0NqWHthXG0PgVt3Xdtx175eNbLw33yKQOvmpOnyjcY8Q@mail.gmail.com>
Message-ID: <CAJ97idHt9rENMx6ZPfLb+-1=MFhP7huWrALtTiHtjuRPmXtjag@mail.gmail.com>

On Wed, May 30, 2018 at 5:20 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> we got some interesting feedback on the Hibernate forums today:
>  - https://discourse.hibernate.org/t/org-hibernate-hibernate-
> orm-modules-no-longer-published/861/5
>
> Is it possible to "add" a feature pack to WildFly with the old
> provisioning tools?
>
> Will it be possible with Galleon?
>

It is.

Alexey

Thanks,
> Sanne
> _______________________________________________
> 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/20180531/ce16de5f/attachment.html 

From david.lloyd at redhat.com  Thu May 31 12:28:51 2018
From: david.lloyd at redhat.com (David Lloyd)
Date: Thu, 31 May 2018 11:28:51 -0500
Subject: [wildfly-dev] Action Required: Security Manager issues
In-Reply-To: <CANghgrT3=FMdSiRJYLfaa3txjA8AYJ59sLiBzc8tTago0S5xMA@mail.gmail.com>
References: <CANghgrRQsdTxe8tPpc5APZnfUV4EdNf2ho_oj+8veQcQ5pWObg@mail.gmail.com>
	<CANghgrT3=FMdSiRJYLfaa3txjA8AYJ59sLiBzc8tTago0S5xMA@mail.gmail.com>
Message-ID: <CANghgrTZJRd38tfV4VCiezWGJ8wxhDPznehmTV21fRcf0GL-hA@mail.gmail.com>

Sorry the original URL is missing a trailing slash after "issues".  So
try this one instead please:

https://issues.jboss.org/issues/?jql=(assignee%20%3D%20currentUser()%20OR%20watcher%20%3D%20currentUser())%20AND%20status%20not%20in%20(resolved%2C%20closed)%20AND%20labels%20%3D%20security-manager

On Thu, May 31, 2018 at 9:49 AM, David Lloyd <david.lloyd at redhat.com> wrote:
> In case that link didn't render for you, you can use
> https://red.ht/2LOk1GP instead.
>
>
>
> On Thu, May 31, 2018 at 9:47 AM, David Lloyd <david.lloyd at redhat.com> wrote:
>> Now that WildFly 13 is released, I would like to ask that everyone
>> please take some time to prioritize and solve the security manager
>> related issues in their area.  These can be found using the query
>> below [1].  If the underlying issue is in an upstream project, please
>> add a "caused by" link to the project in question.
>>
>> If you are not the right person to address a certain issue, then
>> please /cc the right person before you unwatch it to ensure that no
>> issues fall through the cracks.
>>
>> It is my goal to have the security manager CI build [2] running
>> cleanly and integrated into PR processing before the WildFly 14
>> release.
>>
>> Note that some SM problems don't appear as test failures.  I plan to
>> introduce a mechanism whereby all access check failures are logged and
>> we can review this log (perhaps automatically) on each test run.  This
>> however is going to be a future enhancement.
>>
>> [1] https://issues.jboss.org/issues?jql=(assignee%20%3D%20currentUser()%20or%20watcher%20%3D%20currentUser())%20and%20status%20not%20in%20(resolved%2C%20closed)%20and%20labels%20%3D%20"security-manager"
>>
>> [2] https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterSecurityManager
>>
>> --
>> - DML
>
>
>
> --
> - DML



-- 
- DML