[JBoss JIRA] (WFLY-12021) Mixed domain testsuite should remove unneeded expanded dists as it goes
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12021?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-12021:
------------------------------------
Description:
OldVersionCopier unzips the legacy AS zip for the version requested. But there is no subsequent cleanup.
Simplest is to have the method that unzips check for all the other versions besides the one being tested and remove any it finds. The tests execute grouped by version so when work on a new version begins the expanded dist for the previous version is not needed.
That will leave one behind, but that's ok. The problem here is the overall disk utilization during CI jobs and getting this down to just one is ok. And after the last version runs, the CI jobs complete anyway.
was:
OldVersionCopier unzips the legacy AS zip for the version requested. But there is no subsequent cleanup.
Simplest is to have the method that unzips check for all the other versions besides the one being tested and remove any it finds.
That will leave one behind, but that's ok. The problem here is the overall disk utilization during CI jobs and getting this down to just one is fine. And after the last version runs, the CI jobs complete anyway.
> Mixed domain testsuite should remove unneeded expanded dists as it goes
> -----------------------------------------------------------------------
>
> Key: WFLY-12021
> URL: https://issues.jboss.org/browse/WFLY-12021
> Project: WildFly
> Issue Type: Enhancement
> Components: Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> OldVersionCopier unzips the legacy AS zip for the version requested. But there is no subsequent cleanup.
> Simplest is to have the method that unzips check for all the other versions besides the one being tested and remove any it finds. The tests execute grouped by version so when work on a new version begins the expanded dist for the previous version is not needed.
> That will leave one behind, but that's ok. The problem here is the overall disk utilization during CI jobs and getting this down to just one is ok. And after the last version runs, the CI jobs complete anyway.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[JBoss JIRA] (SWSQE-667) Checklist for custom fields in order to support existing and future workflows for Jaeger
by Jeeva Kandasamy (Jira)
[ https://issues.jboss.org/browse/SWSQE-667?page=com.atlassian.jira.plugin.... ]
Jeeva Kandasamy edited comment on SWSQE-667 at 4/26/19 11:13 PM:
-----------------------------------------------------------------
[~pyadav] mentioned, this issue resolved. I am just updating status.
[~pyadav] if it is not resolved, kindly reopen this issue
was (Author: jkandasa):
[~pyadav] mentioned, this issue resolved. I am just updating status.
> Checklist for custom fields in order to support existing and future workflows for Jaeger
> ----------------------------------------------------------------------------------------
>
> Key: SWSQE-667
> URL: https://issues.jboss.org/browse/SWSQE-667
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Prachi Yadav
> Assignee: Jeeva Kandasamy
> Priority: Major
> Labels: pqi
> Attachments: Screenshot from 2019-04-16 18-19-46.png
>
>
> project MUST have the following custom fields in order to support existing and future workflows and visualizations:
> QE Test Coverage with values +, -, and ? (Null is supported)
> SFDC Cases Counter
> SFDC Cases Links
> These custom fields must exist as above so that we do not need to customize logic for any one-offs. The SFDC Cases * fields are there to support "integration" with our SalesForce system used by CEE/GSS for customer cases and the links here are links to SFDC customer cases.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[JBoss JIRA] (SWSQE-667) Checklist for custom fields in order to support existing and future workflows for Jaeger
by Jeeva Kandasamy (Jira)
[ https://issues.jboss.org/browse/SWSQE-667?page=com.atlassian.jira.plugin.... ]
Jeeva Kandasamy resolved SWSQE-667.
-----------------------------------
Resolution: Done
[~pyadav] mentioned, this issue resolved. I am just updating status.
> Checklist for custom fields in order to support existing and future workflows for Jaeger
> ----------------------------------------------------------------------------------------
>
> Key: SWSQE-667
> URL: https://issues.jboss.org/browse/SWSQE-667
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Prachi Yadav
> Assignee: Jeeva Kandasamy
> Priority: Major
> Labels: pqi
> Attachments: Screenshot from 2019-04-16 18-19-46.png
>
>
> project MUST have the following custom fields in order to support existing and future workflows and visualizations:
> QE Test Coverage with values +, -, and ? (Null is supported)
> SFDC Cases Counter
> SFDC Cases Links
> These custom fields must exist as above so that we do not need to customize logic for any one-offs. The SFDC Cases * fields are there to support "integration" with our SalesForce system used by CEE/GSS for customer cases and the links here are links to SFDC customer cases.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[JBoss JIRA] (SWSQE-667) Checklist for custom fields in order to support existing and future workflows for Jaeger
by Jeeva Kandasamy (Jira)
[ https://issues.jboss.org/browse/SWSQE-667?page=com.atlassian.jira.plugin.... ]
Jeeva Kandasamy updated SWSQE-667:
----------------------------------
Sprint: Kiali Sprint #21 (was: Kiali Sprint #22)
> Checklist for custom fields in order to support existing and future workflows for Jaeger
> ----------------------------------------------------------------------------------------
>
> Key: SWSQE-667
> URL: https://issues.jboss.org/browse/SWSQE-667
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Prachi Yadav
> Assignee: Jeeva Kandasamy
> Priority: Major
> Labels: pqi
> Attachments: Screenshot from 2019-04-16 18-19-46.png
>
>
> project MUST have the following custom fields in order to support existing and future workflows and visualizations:
> QE Test Coverage with values +, -, and ? (Null is supported)
> SFDC Cases Counter
> SFDC Cases Links
> These custom fields must exist as above so that we do not need to customize logic for any one-offs. The SFDC Cases * fields are there to support "integration" with our SalesForce system used by CEE/GSS for customer cases and the links here are links to SFDC customer cases.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[JBoss JIRA] (WFLY-12022) Concurrent singleton service installation can cause service to run simultaneously on 2 members.
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-12022:
-----------------------------------
Summary: Concurrent singleton service installation can cause service to run simultaneously on 2 members.
Key: WFLY-12022
URL: https://issues.jboss.org/browse/WFLY-12022
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 16.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
There exists a race condition between concurrent elections triggered by different nodes. In general, only 1 node actually runs the election for a given set of singleton candidates. During a deployment replace, there are a rapid series of changes to the candidates as the deployment is stopped and restarted. While each node processes them 1 at a time, this processing isn't synchronized across members. This is the root of the problem, as a new election can be triggered on one node while another node is still in the process of completing its election. Here's the scenario where observed the race condition:
Before deployment replace, sever-one is the primary provider of the singleton service
Each node undeploys its application, and restarts. As each node redeploys, and the singleton service is reinstalled, each node register itself as providing the singleton service. The redeploy happens concurrently, but the registration order appears the same on all nodes.
In this case, the registration order was server-three, server-two, server-one.
# server-three registers first, it elects itself and starts its service
# server-two registers next
## server-three defers election to server-two
## server-two runs the election:
### Elects itself
### Sends a synchronous service stop message to server-three
### Starts its service
# server-one registers next, while server-two is in the process of stopping the service on server-three
## server-three defers election to server-one
## server-two is still in the election process, but will defer election to server-one once complete
## server-one runs the election:
### Elects itself
### Sends service stop message to server-two and server-three
#### server-three is no longer running its service
#### server-two hasn't yet started its service, but it will soon (This is the problem)
### server-one starts its service
### Meanwhile, server-two just received its response that the stop of service (2.B.II.) and commences its own service start (1.B.III.)
Now server-one and server-two are both running the service.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[JBoss JIRA] (WFLY-12021) Mixed domain testsuite should remove unneeded expanded dists as it goes
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-12021?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFLY-12021:
------------------------------------
Description:
OldVersionCopier unzips the legacy AS zip for the version requested. But there is no subsequent cleanup.
Simplest is to have the method that unzips check for all the other versions besides the one being tested and remove any it finds.
That will leave one behind, but that's ok. The problem here is the overall disk utilization during CI jobs and getting this down to just one is fine. And after the last version runs, the CI jobs complete anyway.
was:
OldVersionCopies unzips the legacy AS zip for the version requested. But there is no subsequent cleanup.
Simplest is to have the method that unzips check for all the other versions besides the one being tested and remove any it finds.
That will leave one behind, but that's ok. The problem here is the overall disk utilization during CI jobs and getting this down to just one is fine. And after the last version runs, the CI jobs complete anyway.
> Mixed domain testsuite should remove unneeded expanded dists as it goes
> -----------------------------------------------------------------------
>
> Key: WFLY-12021
> URL: https://issues.jboss.org/browse/WFLY-12021
> Project: WildFly
> Issue Type: Enhancement
> Components: Management, Test Suite
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
>
> OldVersionCopier unzips the legacy AS zip for the version requested. But there is no subsequent cleanup.
> Simplest is to have the method that unzips check for all the other versions besides the one being tested and remove any it finds.
> That will leave one behind, but that's ok. The problem here is the overall disk utilization during CI jobs and getting this down to just one is fine. And after the last version runs, the CI jobs complete anyway.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[JBoss JIRA] (WFLY-12021) Mixed domain testsuite should remove unneeded expanded dists as it goes
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12021:
---------------------------------------
Summary: Mixed domain testsuite should remove unneeded expanded dists as it goes
Key: WFLY-12021
URL: https://issues.jboss.org/browse/WFLY-12021
Project: WildFly
Issue Type: Enhancement
Components: Management, Test Suite
Reporter: Brian Stansberry
Assignee: Brian Stansberry
OldVersionCopies unzips the legacy AS zip for the version requested. But there is no subsequent cleanup.
Simplest is to have the method that unzips check for all the other versions besides the one being tested and remove any it finds.
That will leave one behind, but that's ok. The problem here is the overall disk utilization during CI jobs and getting this down to just one is fine. And after the last version runs, the CI jobs complete anyway.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Ronald Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Ronald Sigal commented on WFLY-11956:
-------------------------------------
Ok, consider
{code}
int id = 3;
@Path("id")
@GET
@Max(7)
public int getId() {
return id;
}
{code}
If I understand correctly, the value returned by getId() will be validated while the object is being constructed, and, by default, will not be validated if getId() is called as a resource method. That makes some sense, since it would be redundant to validate it again.
Now, consider
{code}
int count = 0;
@Path("count")
@GET
@Max(1)
public int getCount() {
return count++;
}
{code}
When the return value of getCount() is validated at object construction time, it will pass. But if it were validated again when getCount() is called as a resource method, it would fail.
The point I'm trying to make is just that things get weird when a resource method looks like a getter. Note that the paragraph in Section 7.4 referred to by Santiago tries to make the same point:
{code}
Note that if validation for getter methods is enabled and a resource method’s signature obeys the rules for
getters, the resource method may be (unintentionally) invoked during validation. Conversely, if validation
for getter methods is disabled and the matching resource method’s signature obeys the rules for getters,
the JAX-RS runtime will still validate the method (i.e., the validation preference will be ignored) before
invocation.
{code}
I think the point (don't write resource methods that look like getter methods) is valid, but the details aren't right. I would say something like
{code}
Properties, which are characterized by the presence of a related getter method, are validated at object construction time. In particular,
the method is executed and the return value is validated. *N.B.* It is possible, but not a good idea, to write a resource method that also satisfies the
conditions to be a getter method. In that case, it will be treated and validated as a getter at object creation time, but, by default, since getters are not constrained methods, the return value will not be validated when the method is called as a resource method.
{code}
Does that sound right to anyone?
> @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11956
> URL: https://issues.jboss.org/browse/WFLY-11956
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, REST
> Affects Versions: 16.0.0.Final
> Reporter: Joerg Baesner
> Assignee: Ronald Sigal
> Priority: Major
> Attachments: logging.txt, playground.zip
>
>
> Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_:
> {code}
> @Path("/validated")
> public interface ValidatedJaxRsInterface {
>
> @GET
> @Valid
> @Produces(MediaType.APPLICATION_JSON)
> GreetingModel getHelloGreeting();
> }
> {code}
> will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed.
> This can be reproduced with the attached reproducer application...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[JBoss JIRA] (WFLY-12020) Refresh Infinispan cache metrics
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-12020:
-----------------------------------
Summary: Refresh Infinispan cache metrics
Key: WFLY-12020
URL: https://issues.jboss.org/browse/WFLY-12020
Project: WildFly
Issue Type: Task
Components: Clustering
Affects Versions: 16.0.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The cache metrics exposes by WildFly were setup a long time ago. The set of metrics we expose should be reassessed, deprecating those that don't make sense within the context of WildFly (e.g. cache-status), and adding those that do make sense, but are missing from WildFly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months
[JBoss JIRA] (WFLY-11956) @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
by Ronald Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-11956?page=com.atlassian.jira.plugin... ]
Ronald Sigal edited comment on WFLY-11956 at 4/26/19 4:54 PM:
--------------------------------------------------------------
[~gunnar.morling], I got a response from Santiago. I'm still digesting it. \[Santiago's remarks are in red.\]
========================================
{color:#DE350B}Hi Ron,
See inline.
{color}
> Hi Santiago,
>
> I just created https://github.com/eclipse-ee4j/jaxrs-api/issues/759.
>
> As for the "if enabled", I had some confusion on that point, but then I thought Guillaume Smet from the Hibernate Validator project clarified it. In particular, he said that GreetingModel in
>
> @GET
> @Valid
> @Produces(MediaType.APPLICATION_JSON)
> GreetingModel getHelloGreeting() {...}
>
> is getting validated during the property validation phase, rather than when getHelloGretting() is called as a resource method.
{color:#DE350B}Right, so having a resource method that looks like a getter is bad idea to begin with. Section 7.4 of the JAX-RS spec talks specifically about this case.{color}
>
> To quote him, "When validating the bean in JaxrsInjectionTarget, you validate the bean itself and thus all its properties - so all the fields and getters. It is not method validation but property validation. That's why your configuration in the XML file is useless. Getters are already not validated methods by default. But... they are validated when you validate the properties of a bean", where, by "your configuration in the XML file" he is referring to
>
> <executable-validation>
> <default-validated-executable-types>
> <executable-type>CONSTRUCTORS</executable-type>
> <executable-type>NON_GETTER_METHODS</executable-type>
> </default-validated-executable-types>
> </executable-validation>
>
> So, the point is that there seems to be no mechanism for disabling getter validation during the field/property validation phase. So "if enabled" doesn't seem to be applicable. Does that make sense?
{color:#DE350B}Looks like there may have been some confusion here. We certainly heard at the time “Getters are not validated by default” and that is what prompted the creation of Section 7.4. I don’t believe we heard that they were validated in some other phase. If so, there’s a clear disconnect in the JAX-RS spec.
It’s interesting because the JAX-RS spec was reviewed by validation experts at the time. I must say, it would make more sense for getters to be validated. Perhaps the scope of your issue needs to be broaden to cover this …
— Santiago{color}
> On 4/26/19 2:05 PM, Santiago
> Pericas-Geertsen wrote:
{color:#DE350B}>> Ron,
>>
>> I agree, the JAX-RS spec should mention @PostContruct as part of the validation process. Do you want to file an issue?
>>
>> Incidentally, the “if enabled” is because getters are not validated by default as described in Section 7.4 of the JAX-RS spec.
>>
>> — Santiago{color}
>>
>>> On Apr 26, 2019, at 12:03 PM, Ron Sigal <rsigal(a)redhat.com> wrote:
>>>
>>> The spirit of the validation process is that validation of fields/properties should take place after injection and initialization has occurred. Given that further initialization could take place in a @PostConstruct annotated method, shouldn't the spec mention that?
>>>
>>> This question arose from discussion in https://issues.jboss.org/browse/WFLY-11956 "@PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method".
>>>
>>> -Ron
was (Author: ron_sigal):
[~gunnar.morling], I got a response from Santiago. I'm still digesting it:
========================================
Hi Ron,
See inline.
> Hi Santiago,
>
> I just created https://github.com/eclipse-ee4j/jaxrs-api/issues/759.
>
> As for the "if enabled", I had some confusion on that point, but then I thought Guillaume Smet from the Hibernate Validator project clarified it. In particular, he said that GreetingModel in
>
> @GET
> @Valid
> @Produces(MediaType.APPLICATION_JSON)
> GreetingModel getHelloGreeting() {...}
>
> is getting validated during the property validation phase, rather than when getHelloGretting() is called as a resource method.
Right, so having a resource method that looks like a getter is bad idea to begin with. Section 7.4 of the JAX-RS spec talks specifically about this case.
>
> To quote him, "When validating the bean in JaxrsInjectionTarget, you validate the bean itself and thus all its properties - so all the fields and getters. It is not method validation but property validation. That's why your configuration in the XML file is useless. Getters are already not validated methods by default. But... they are validated when you validate the properties of a bean", where, by "your configuration in the XML file" he is referring to
>
> <executable-validation>
> <default-validated-executable-types>
> <executable-type>CONSTRUCTORS</executable-type>
> <executable-type>NON_GETTER_METHODS</executable-type>
> </default-validated-executable-types>
> </executable-validation>
>
> So, the point is that there seems to be no mechanism for disabling getter validation during the field/property validation phase. So "if enabled" doesn't seem to be applicable. Does that make sense?
Looks like there may have been some confusion here. We certainly heard at the time “Getters are not validated by default” and that is what prompted the creation of Section 7.4. I don’t believe we heard that they were validated in some other phase. If so, there’s a clear disconnect in the JAX-RS spec.
It’s interesting because the JAX-RS spec was reviewed by validation experts at the time. I must say, it would make more sense for getters to be validated. Perhaps the scope of your issue needs to be broaden to cover this …
— Santiago
> On 4/26/19 2:05 PM, Santiago
> Pericas-Geertsen wrote:
>> Ron,
>>
>> I agree, the JAX-RS spec should mention @PostContruct as part of the validation process. Do you want to file an issue?
>>
>> Incidentally, the “if enabled” is because getters are not validated by default as described in Section 7.4 of the JAX-RS spec.
>>
>> — Santiago
>>
>>> On Apr 26, 2019, at 12:03 PM, Ron Sigal <rsigal(a)redhat.com> wrote:
>>>
>>> The spirit of the validation process is that validation of fields/properties should take place after injection and initialization has occurred. Given that further initialization could take place in a @PostConstruct annotated method, shouldn't the spec mention that?
>>>
>>> This question arose from discussion in https://issues.jboss.org/browse/WFLY-11956 "@PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method".
>>>
>>> -Ron
> @PostConstruct on @ApplicationScoped bean called too late in case @Valid is annotated on a business method
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11956
> URL: https://issues.jboss.org/browse/WFLY-11956
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, REST
> Affects Versions: 16.0.0.Final
> Reporter: Joerg Baesner
> Assignee: Ronald Sigal
> Priority: Major
> Attachments: logging.txt, playground.zip
>
>
> Having a bean class with {{@ApplicationScoped}}, which has a {{@PostConstruct}} and is implementing the following _Interface_:
> {code}
> @Path("/validated")
> public interface ValidatedJaxRsInterface {
>
> @GET
> @Valid
> @Produces(MediaType.APPLICATION_JSON)
> GreetingModel getHelloGreeting();
> }
> {code}
> will result in calling the {{getHelloGreeting}} method of the implementation class twice *_before_* the {{@PostConstruct}} is getting executed.
> This can be reproduced with the attached reproducer application...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 6 months