Version ownership (conflict?): Apache Avro

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Version ownership (conflict?): Apache Avro

Sanne Grinovero
Hi all,

I just noticed that the Apache Avro version included in WildFly was
upgraded to 1.8.1.

This breaks Hibernate Search. It wasn't caught by automated
integration tests as this aspect wasn't covered by integration tests
within the wildfly codebase - we have them within Hibernate.

A quick grep on the module definitions doesn't reveal any other user,
and "git blame" seems to suggest it was updated just for the sake of
updating some components.. so I'm guessing there is no other
stackeholder I should align with?

1# Could we please revert it to 1.7.6, which is what Hibernate Search requires?

Alternatively we'll need some ad-hoc coding on Hibernate Search and a
new version respin - with all associated risks - just for the sake of
updating this.

2# What can we do to prevent such things in the future?

I can of course contribute some more integration tests but it's never
going to be enough: there will always be more tests "upstream". Could
we rather agree on some improved communication process when you all
consider updating an indirect dependency?

Thanks,
Sanne

 - https://issues.jboss.org/browse/WFLY-9221
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version ownership (conflict?): Apache Avro

James Perkins
It looks like it came in as part of https://issues.jboss.org/browse/WFLY-7908. I'm personally not a big fan of these sweeping version updates like this for this exact reason. We've had issues with this type of thing before and I do think we need a better approach.

IMO we can definitely downgrade this. I also see no other modules that depend on it either.

On Fri, Aug 11, 2017 at 2:43 PM, Sanne Grinovero <[hidden email]> wrote:
Hi all,

I just noticed that the Apache Avro version included in WildFly was
upgraded to 1.8.1.

This breaks Hibernate Search. It wasn't caught by automated
integration tests as this aspect wasn't covered by integration tests
within the wildfly codebase - we have them within Hibernate.

A quick grep on the module definitions doesn't reveal any other user,
and "git blame" seems to suggest it was updated just for the sake of
updating some components.. so I'm guessing there is no other
stackeholder I should align with?

1# Could we please revert it to 1.7.6, which is what Hibernate Search requires?

Alternatively we'll need some ad-hoc coding on Hibernate Search and a
new version respin - with all associated risks - just for the sake of
updating this.

2# What can we do to prevent such things in the future?

I can of course contribute some more integration tests but it's never
going to be enough: there will always be more tests "upstream". Could
we rather agree on some improved communication process when you all
consider updating an indirect dependency?

Thanks,
Sanne

 - https://issues.jboss.org/browse/WFLY-9221
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version ownership (conflict?): Apache Avro

Sanne Grinovero
Thanks James! I've sent a PR to restore the previous version.

I'll be checking some more cross-project dependency requirements next weeek.

On 12 August 2017 at 01:08, James Perkins <[hidden email]> wrote:

> It looks like it came in as part of
> https://issues.jboss.org/browse/WFLY-7908. I'm personally not a big fan of
> these sweeping version updates like this for this exact reason. We've had
> issues with this type of thing before and I do think we need a better
> approach.
>
> IMO we can definitely downgrade this. I also see no other modules that
> depend on it either.
>
> On Fri, Aug 11, 2017 at 2:43 PM, Sanne Grinovero <[hidden email]>
> wrote:
>>
>> Hi all,
>>
>> I just noticed that the Apache Avro version included in WildFly was
>> upgraded to 1.8.1.
>>
>> This breaks Hibernate Search. It wasn't caught by automated
>> integration tests as this aspect wasn't covered by integration tests
>> within the wildfly codebase - we have them within Hibernate.
>>
>> A quick grep on the module definitions doesn't reveal any other user,
>> and "git blame" seems to suggest it was updated just for the sake of
>> updating some components.. so I'm guessing there is no other
>> stackeholder I should align with?
>>
>> 1# Could we please revert it to 1.7.6, which is what Hibernate Search
>> requires?
>>
>> Alternatively we'll need some ad-hoc coding on Hibernate Search and a
>> new version respin - with all associated risks - just for the sake of
>> updating this.
>>
>> 2# What can we do to prevent such things in the future?
>>
>> I can of course contribute some more integration tests but it's never
>> going to be enough: there will always be more tests "upstream". Could
>> we rather agree on some improved communication process when you all
>> consider updating an indirect dependency?
>>
>> Thanks,
>> Sanne
>>
>>  - https://issues.jboss.org/browse/WFLY-9221
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version ownership (conflict?): Apache Avro

Carlo de Wolf
These form of conflicts must be guarded in a test(suite) that is part of
WildFly release criteria.

Carlo

On 08/12/2017 11:44 AM, Sanne Grinovero wrote:

> Thanks James! I've sent a PR to restore the previous version.
>
> I'll be checking some more cross-project dependency requirements next weeek.
>
> On 12 August 2017 at 01:08, James Perkins <[hidden email]> wrote:
>> It looks like it came in as part of
>> https://issues.jboss.org/browse/WFLY-7908. I'm personally not a big fan of
>> these sweeping version updates like this for this exact reason. We've had
>> issues with this type of thing before and I do think we need a better
>> approach.
>>
>> IMO we can definitely downgrade this. I also see no other modules that
>> depend on it either.
>>
>> On Fri, Aug 11, 2017 at 2:43 PM, Sanne Grinovero <[hidden email]>
>> wrote:
>>> Hi all,
>>>
>>> I just noticed that the Apache Avro version included in WildFly was
>>> upgraded to 1.8.1.
>>>
>>> This breaks Hibernate Search. It wasn't caught by automated
>>> integration tests as this aspect wasn't covered by integration tests
>>> within the wildfly codebase - we have them within Hibernate.
>>>
>>> A quick grep on the module definitions doesn't reveal any other user,
>>> and "git blame" seems to suggest it was updated just for the sake of
>>> updating some components.. so I'm guessing there is no other
>>> stackeholder I should align with?
>>>
>>> 1# Could we please revert it to 1.7.6, which is what Hibernate Search
>>> requires?
>>>
>>> Alternatively we'll need some ad-hoc coding on Hibernate Search and a
>>> new version respin - with all associated risks - just for the sake of
>>> updating this.
>>>
>>> 2# What can we do to prevent such things in the future?
>>>
>>> I can of course contribute some more integration tests but it's never
>>> going to be enough: there will always be more tests "upstream". Could
>>> we rather agree on some improved communication process when you all
>>> consider updating an indirect dependency?
>>>
>>> Thanks,
>>> Sanne
>>>
>>>   - https://issues.jboss.org/browse/WFLY-9221
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> --
>> James R. Perkins
>> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version ownership (conflict?): Apache Avro

James Perkins
There's no way we can have tests for every feature that every project brings into WildFly.

On Mon, Aug 14, 2017 at 1:00 AM, Carlo de Wolf <[hidden email]> wrote:
These form of conflicts must be guarded in a test(suite) that is part of WildFly release criteria.

Carlo


On 08/12/2017 11:44 AM, Sanne Grinovero wrote:
Thanks James! I've sent a PR to restore the previous version.

I'll be checking some more cross-project dependency requirements next weeek.

On 12 August 2017 at 01:08, James Perkins <[hidden email]> wrote:
It looks like it came in as part of
https://issues.jboss.org/browse/WFLY-7908. I'm personally not a big fan of
these sweeping version updates like this for this exact reason. We've had
issues with this type of thing before and I do think we need a better
approach.

IMO we can definitely downgrade this. I also see no other modules that
depend on it either.

On Fri, Aug 11, 2017 at 2:43 PM, Sanne Grinovero <[hidden email]>
wrote:
Hi all,

I just noticed that the Apache Avro version included in WildFly was
upgraded to 1.8.1.

This breaks Hibernate Search. It wasn't caught by automated
integration tests as this aspect wasn't covered by integration tests
within the wildfly codebase - we have them within Hibernate.

A quick grep on the module definitions doesn't reveal any other user,
and "git blame" seems to suggest it was updated just for the sake of
updating some components.. so I'm guessing there is no other
stackeholder I should align with?

1# Could we please revert it to 1.7.6, which is what Hibernate Search
requires?

Alternatively we'll need some ad-hoc coding on Hibernate Search and a
new version respin - with all associated risks - just for the sake of
updating this.

2# What can we do to prevent such things in the future?

I can of course contribute some more integration tests but it's never
going to be enough: there will always be more tests "upstream". Could
we rather agree on some improved communication process when you all
consider updating an indirect dependency?

Thanks,
Sanne

  - https://issues.jboss.org/browse/WFLY-9221
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
James R. Perkins
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev






--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version ownership (conflict?): Apache Avro

Sanne Grinovero
On 14 August 2017 at 15:48, James Perkins <[hidden email]> wrote:
> There's no way we can have tests for every feature that every project brings
> into WildFly.

Indeed: we could add some more tests, but there's a practical limit;
the combined Hibernate projects would potentially contribute some
~8000 additional tests - but that's also adding some 3 hours testing
to each build, which doesn't scale.
You might want to hand-pick some strategical ones covering
integration, but such a manual selection is bound to be out of date in
no time.

On the other hand Carlo make a good point: the need to make sure such
things don't happen again.

I suspect the solution is to be found in some evolution of the
"feature packs" concept. The primary problem is that in upstream
(Hibernate projects) we pick our own dependencies and build our own
modules.
This same structure is then replicated in WildFly, but the structure
of the modules and the versions are just crafted by humans to look
like the same - which introduces the need for us to "watch" what
you're all changing, as versions could drift apart, to the point of
not actually working correctly in some cases.
We need to make sure that the very same combination of module
definitions and dependencies that we use to test upstream is
incorporater verbatim into WildFly.

That would be a reliable solution, and without the need to expand on
the testsuite dimensions - neither code (maintenance) nor build times.
It would also avoid you all needing to install the 30+ RDBMS vendors &
versions we support to actually run all those tests.

Tomaž had kindly contributed a prototype for Hibernate Search to
publish feature packs, and I loved the idea as it addresses such
problems, but then we failed to find a consensus about how this would
work.
I'm still looking forward to hear some clarification on such plans:
 - http://lists.jboss.org/pipermail/wildfly-dev/2017-January/005686.html

Thanks,
Sanne


> On Mon, Aug 14, 2017 at 1:00 AM, Carlo de Wolf <[hidden email]> wrote:
>>
>> These form of conflicts must be guarded in a test(suite) that is part of
>> WildFly release criteria.
>>
>> Carlo
>>
>>
>> On 08/12/2017 11:44 AM, Sanne Grinovero wrote:
>>>
>>> Thanks James! I've sent a PR to restore the previous version.
>>>
>>> I'll be checking some more cross-project dependency requirements next
>>> weeek.
>>>
>>> On 12 August 2017 at 01:08, James Perkins <[hidden email]> wrote:
>>>>
>>>> It looks like it came in as part of
>>>> https://issues.jboss.org/browse/WFLY-7908. I'm personally not a big fan
>>>> of
>>>> these sweeping version updates like this for this exact reason. We've
>>>> had
>>>> issues with this type of thing before and I do think we need a better
>>>> approach.
>>>>
>>>> IMO we can definitely downgrade this. I also see no other modules that
>>>> depend on it either.
>>>>
>>>> On Fri, Aug 11, 2017 at 2:43 PM, Sanne Grinovero <[hidden email]>
>>>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I just noticed that the Apache Avro version included in WildFly was
>>>>> upgraded to 1.8.1.
>>>>>
>>>>> This breaks Hibernate Search. It wasn't caught by automated
>>>>> integration tests as this aspect wasn't covered by integration tests
>>>>> within the wildfly codebase - we have them within Hibernate.
>>>>>
>>>>> A quick grep on the module definitions doesn't reveal any other user,
>>>>> and "git blame" seems to suggest it was updated just for the sake of
>>>>> updating some components.. so I'm guessing there is no other
>>>>> stackeholder I should align with?
>>>>>
>>>>> 1# Could we please revert it to 1.7.6, which is what Hibernate Search
>>>>> requires?
>>>>>
>>>>> Alternatively we'll need some ad-hoc coding on Hibernate Search and a
>>>>> new version respin - with all associated risks - just for the sake of
>>>>> updating this.
>>>>>
>>>>> 2# What can we do to prevent such things in the future?
>>>>>
>>>>> I can of course contribute some more integration tests but it's never
>>>>> going to be enough: there will always be more tests "upstream". Could
>>>>> we rather agree on some improved communication process when you all
>>>>> consider updating an indirect dependency?
>>>>>
>>>>> Thanks,
>>>>> Sanne
>>>>>
>>>>>   - https://issues.jboss.org/browse/WFLY-9221
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> James R. Perkins
>>>> JBoss by Red Hat
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>
>
>
>
> --
> James R. Perkins
> JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version ownership (conflict?): Apache Avro

Carlo de Wolf
That would be no different than a project provisioning the runtime. At
which point the project can do whatever tests they see fit to ensure
final integration into the product.

Tie to this component upgrades being dictated from down the lines of
dependencies instead of coming from above and I think you would have all
bases covered.

Carlo

On 08/14/2017 05:24 PM, Sanne Grinovero wrote:

> On 14 August 2017 at 15:48, James Perkins <[hidden email]> wrote:
>> There's no way we can have tests for every feature that every project brings
>> into WildFly.
> Indeed: we could add some more tests, but there's a practical limit;
> the combined Hibernate projects would potentially contribute some
> ~8000 additional tests - but that's also adding some 3 hours testing
> to each build, which doesn't scale.
> You might want to hand-pick some strategical ones covering
> integration, but such a manual selection is bound to be out of date in
> no time.
>
> On the other hand Carlo make a good point: the need to make sure such
> things don't happen again.
>
> I suspect the solution is to be found in some evolution of the
> "feature packs" concept. The primary problem is that in upstream
> (Hibernate projects) we pick our own dependencies and build our own
> modules.
> This same structure is then replicated in WildFly, but the structure
> of the modules and the versions are just crafted by humans to look
> like the same - which introduces the need for us to "watch" what
> you're all changing, as versions could drift apart, to the point of
> not actually working correctly in some cases.
> We need to make sure that the very same combination of module
> definitions and dependencies that we use to test upstream is
> incorporater verbatim into WildFly.
>
> That would be a reliable solution, and without the need to expand on
> the testsuite dimensions - neither code (maintenance) nor build times.
> It would also avoid you all needing to install the 30+ RDBMS vendors &
> versions we support to actually run all those tests.
>
> Tomaž had kindly contributed a prototype for Hibernate Search to
> publish feature packs, and I loved the idea as it addresses such
> problems, but then we failed to find a consensus about how this would
> work.
> I'm still looking forward to hear some clarification on such plans:
>   - http://lists.jboss.org/pipermail/wildfly-dev/2017-January/005686.html
>
> Thanks,
> Sanne
>
>
>> On Mon, Aug 14, 2017 at 1:00 AM, Carlo de Wolf <[hidden email]> wrote:
>>> These form of conflicts must be guarded in a test(suite) that is part of
>>> WildFly release criteria.
>>>
>>> Carlo
>>>
>>>
>>> On 08/12/2017 11:44 AM, Sanne Grinovero wrote:
>>>> Thanks James! I've sent a PR to restore the previous version.
>>>>
>>>> I'll be checking some more cross-project dependency requirements next
>>>> weeek.
>>>>
>>>> On 12 August 2017 at 01:08, James Perkins <[hidden email]> wrote:
>>>>> It looks like it came in as part of
>>>>> https://issues.jboss.org/browse/WFLY-7908. I'm personally not a big fan
>>>>> of
>>>>> these sweeping version updates like this for this exact reason. We've
>>>>> had
>>>>> issues with this type of thing before and I do think we need a better
>>>>> approach.
>>>>>
>>>>> IMO we can definitely downgrade this. I also see no other modules that
>>>>> depend on it either.
>>>>>
>>>>> On Fri, Aug 11, 2017 at 2:43 PM, Sanne Grinovero <[hidden email]>
>>>>> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I just noticed that the Apache Avro version included in WildFly was
>>>>>> upgraded to 1.8.1.
>>>>>>
>>>>>> This breaks Hibernate Search. It wasn't caught by automated
>>>>>> integration tests as this aspect wasn't covered by integration tests
>>>>>> within the wildfly codebase - we have them within Hibernate.
>>>>>>
>>>>>> A quick grep on the module definitions doesn't reveal any other user,
>>>>>> and "git blame" seems to suggest it was updated just for the sake of
>>>>>> updating some components.. so I'm guessing there is no other
>>>>>> stackeholder I should align with?
>>>>>>
>>>>>> 1# Could we please revert it to 1.7.6, which is what Hibernate Search
>>>>>> requires?
>>>>>>
>>>>>> Alternatively we'll need some ad-hoc coding on Hibernate Search and a
>>>>>> new version respin - with all associated risks - just for the sake of
>>>>>> updating this.
>>>>>>
>>>>>> 2# What can we do to prevent such things in the future?
>>>>>>
>>>>>> I can of course contribute some more integration tests but it's never
>>>>>> going to be enough: there will always be more tests "upstream". Could
>>>>>> we rather agree on some improved communication process when you all
>>>>>> consider updating an indirect dependency?
>>>>>>
>>>>>> Thanks,
>>>>>> Sanne
>>>>>>
>>>>>>    - https://issues.jboss.org/browse/WFLY-9221
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> James R. Perkins
>>>>> JBoss by Red Hat
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>>
>>
>>
>> --
>> James R. Perkins
>> JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Version ownership (conflict?): Apache Avro

Sanne Grinovero


On 15 Aug 2017 08:17, "Carlo de Wolf" <[hidden email]> wrote:
That would be no different than a project provisioning the runtime. At which point the project can do whatever tests they see fit to ensure final integration into the product.

Tie to this component upgrades being dictated from down the lines of dependencies instead of coming from above and I think you would have all bases covered.

+1 that would be awesome. 

In the Hibernate team we'd be open to volunteer testing such a new process but we're looking forward for directions from the WildFly team... or shall we just move forward with the current notion of feature packs? I heard rumours of someone to experiment with new tools? Please let us know.

Thanks
Sanne 






Carlo


On 08/14/2017 05:24 PM, Sanne Grinovero wrote:
On 14 August 2017 at 15:48, James Perkins <[hidden email]> wrote:
There's no way we can have tests for every feature that every project brings
into WildFly.
Indeed: we could add some more tests, but there's a practical limit;
the combined Hibernate projects would potentially contribute some
~8000 additional tests - but that's also adding some 3 hours testing
to each build, which doesn't scale.
You might want to hand-pick some strategical ones covering
integration, but such a manual selection is bound to be out of date in
no time.

On the other hand Carlo make a good point: the need to make sure such
things don't happen again.

I suspect the solution is to be found in some evolution of the
"feature packs" concept. The primary problem is that in upstream
(Hibernate projects) we pick our own dependencies and build our own
modules.
This same structure is then replicated in WildFly, but the structure
of the modules and the versions are just crafted by humans to look
like the same - which introduces the need for us to "watch" what
you're all changing, as versions could drift apart, to the point of
not actually working correctly in some cases.
We need to make sure that the very same combination of module
definitions and dependencies that we use to test upstream is
incorporater verbatim into WildFly.

That would be a reliable solution, and without the need to expand on
the testsuite dimensions - neither code (maintenance) nor build times.
It would also avoid you all needing to install the 30+ RDBMS vendors &
versions we support to actually run all those tests.

Tomaž had kindly contributed a prototype for Hibernate Search to
publish feature packs, and I loved the idea as it addresses such
problems, but then we failed to find a consensus about how this would
work.
I'm still looking forward to hear some clarification on such plans:
  - http://lists.jboss.org/pipermail/wildfly-dev/2017-January/005686.html

Thanks,
Sanne


On Mon, Aug 14, 2017 at 1:00 AM, Carlo de Wolf <[hidden email]> wrote:
These form of conflicts must be guarded in a test(suite) that is part of
WildFly release criteria.

Carlo


On 08/12/2017 11:44 AM, Sanne Grinovero wrote:
Thanks James! I've sent a PR to restore the previous version.

I'll be checking some more cross-project dependency requirements next
weeek.

On 12 August 2017 at 01:08, James Perkins <[hidden email]> wrote:
It looks like it came in as part of
https://issues.jboss.org/browse/WFLY-7908. I'm personally not a big fan
of
these sweeping version updates like this for this exact reason. We've
had
issues with this type of thing before and I do think we need a better
approach.

IMO we can definitely downgrade this. I also see no other modules that
depend on it either.

On Fri, Aug 11, 2017 at 2:43 PM, Sanne Grinovero <[hidden email]>
wrote:
Hi all,

I just noticed that the Apache Avro version included in WildFly was
upgraded to 1.8.1.

This breaks Hibernate Search. It wasn't caught by automated
integration tests as this aspect wasn't covered by integration tests
within the wildfly codebase - we have them within Hibernate.

A quick grep on the module definitions doesn't reveal any other user,
and "git blame" seems to suggest it was updated just for the sake of
updating some components.. so I'm guessing there is no other
stackeholder I should align with?

1# Could we please revert it to 1.7.6, which is what Hibernate Search
requires?

Alternatively we'll need some ad-hoc coding on Hibernate Search and a
new version respin - with all associated risks - just for the sake of
updating this.

2# What can we do to prevent such things in the future?

I can of course contribute some more integration tests but it's never
going to be enough: there will always be more tests "upstream". Could
we rather agree on some improved communication process when you all
consider updating an indirect dependency?

Thanks,
Sanne

   - https://issues.jboss.org/browse/WFLY-9221
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
James R. Perkins
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev




--
James R. Perkins
JBoss by Red Hat



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev