[JBoss JIRA] (WFLY-6965) Audit @Ignore-d clustering tests
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6965?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6965:
---------------------------------
Description:
Recently stumbling upon an @Ignore-d test which would have caught a regression, we need to audit ignored clustering tests, e.g. some are referencing already fixed issues.
{noformat}
[rhusar@syrah clustering]$ git grep @Ignore
src/test/java/org/jboss/as/test/clustering/cluster/ejb/remote/RemoteFailoverTestCase.java: @Ignore("WFLY-3532")
src/test/java/org/jboss/as/test/clustering/cluster/ejb/stateful/StatefulFailoverTestCase.java: @Ignore("WFLY-835 @Resource UserTransaction error when file passivation store is selected")
src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/CoarseSessionPassivationTestCase.java:@Ignore("WFLY-6624")
src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/FineSessionPassivationTestCase.java:@Ignore("WFLY-6624")
src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/passivation/ClusterPassivationTestCase.java: @Ignore("JBPAPP-8774")
src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726")
src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726")
src/test/java/org/jboss/as/test/clustering/single/jdbcstore/TransactionalJdbcStoreTestCase.java:@Ignore("https://issues.jboss.org/browse/ISPN-604")
src/test/java/org/jboss/as/test/clustering/xsite/XSiteSimpleTestCase.java: @Ignore("https://issues.jboss.org/browse/WFLY-5239")
{noformat}
was:Recently stumbling upon an @Ignore-d test which would have caught a regression, we need to audit ignored clustering tests, e.g. some are referencing already fixed issues.
> Audit @Ignore-d clustering tests
> --------------------------------
>
> Key: WFLY-6965
> URL: https://issues.jboss.org/browse/WFLY-6965
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Affects Versions: 10.1.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> Recently stumbling upon an @Ignore-d test which would have caught a regression, we need to audit ignored clustering tests, e.g. some are referencing already fixed issues.
> {noformat}
> [rhusar@syrah clustering]$ git grep @Ignore
> src/test/java/org/jboss/as/test/clustering/cluster/ejb/remote/RemoteFailoverTestCase.java: @Ignore("WFLY-3532")
> src/test/java/org/jboss/as/test/clustering/cluster/ejb/stateful/StatefulFailoverTestCase.java: @Ignore("WFLY-835 @Resource UserTransaction error when file passivation store is selected")
> src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/CoarseSessionPassivationTestCase.java:@Ignore("WFLY-6624")
> src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/FineSessionPassivationTestCase.java:@Ignore("WFLY-6624")
> src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/passivation/ClusterPassivationTestCase.java: @Ignore("JBPAPP-8774")
> src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726")
> src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726")
> src/test/java/org/jboss/as/test/clustering/single/jdbcstore/TransactionalJdbcStoreTestCase.java:@Ignore("https://issues.jboss.org/browse/ISPN-604")
> src/test/java/org/jboss/as/test/clustering/xsite/XSiteSimpleTestCase.java: @Ignore("https://issues.jboss.org/browse/WFLY-5239")
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6965) Audit @Ignore-d clustering integration tests
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-6965?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-6965:
---------------------------------
Summary: Audit @Ignore-d clustering integration tests (was: Audit @Ignore-d clustering tests)
> Audit @Ignore-d clustering integration tests
> --------------------------------------------
>
> Key: WFLY-6965
> URL: https://issues.jboss.org/browse/WFLY-6965
> Project: WildFly
> Issue Type: Task
> Components: Clustering
> Affects Versions: 10.1.0.CR1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> Recently stumbling upon an @Ignore-d test which would have caught a regression, we need to audit ignored clustering tests, e.g. some are referencing already fixed issues.
> {noformat}
> [rhusar@syrah clustering]$ git grep @Ignore
> src/test/java/org/jboss/as/test/clustering/cluster/ejb/remote/RemoteFailoverTestCase.java: @Ignore("WFLY-3532")
> src/test/java/org/jboss/as/test/clustering/cluster/ejb/stateful/StatefulFailoverTestCase.java: @Ignore("WFLY-835 @Resource UserTransaction error when file passivation store is selected")
> src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/CoarseSessionPassivationTestCase.java:@Ignore("WFLY-6624")
> src/test/java/org/jboss/as/test/clustering/cluster/web/passivation/FineSessionPassivationTestCase.java:@Ignore("WFLY-6624")
> src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/passivation/ClusterPassivationTestCase.java: @Ignore("JBPAPP-8774")
> src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726")
> src/test/java/org/jboss/as/test/clustering/extended/ejb2/stateful/remote/failover/dd/RemoteEJB2ClientStatefulBeanFailoverDDTestCase.java: @Ignore("JBPAPP-8726")
> src/test/java/org/jboss/as/test/clustering/single/jdbcstore/TransactionalJdbcStoreTestCase.java:@Ignore("https://issues.jboss.org/browse/ISPN-604")
> src/test/java/org/jboss/as/test/clustering/xsite/XSiteSimpleTestCase.java: @Ignore("https://issues.jboss.org/browse/WFLY-5239")
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6965) Audit @Ignore-d clustering tests
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-6965:
------------------------------------
Summary: Audit @Ignore-d clustering tests
Key: WFLY-6965
URL: https://issues.jboss.org/browse/WFLY-6965
Project: WildFly
Issue Type: Task
Components: Clustering
Affects Versions: 10.1.0.CR1
Reporter: Radoslav Husar
Assignee: Radoslav Husar
Recently stumbling upon an @Ignore-d test which would have caught a regression, we need to audit ignored clustering tests, e.g. some are referencing already fixed issues.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6858) read-resource should return the job file name
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6858?page=com.atlassian.jira.plugin.... ]
James Perkins edited comment on WFLY-6858 at 8/16/16 1:45 PM:
--------------------------------------------------------------
If it helps too we could have a list of all the valid XML files on the base {{/deployment=*/subsystem=batch-jberet}} resource too.
{code}
{
"outcome" => "success",
"result" => {
"job-xml-names" => [
"simple.xml",
"retry-chunk.xml",
"partition-chunk.xml"
],
"job" => {
"simple" => {
"instance-count" => 0,
"job-xml-names" => ["simple.xml"],
"running-executions" => 0,
"execution" => undefined
},
"chunkPartition" => {
"instance-count" => 0,
"job-xml-names" => [
"retry-chunk.xml",
"partition-chunk.xml"
],
"running-executions" => 0,
"execution" => undefined
}
}
}
}
{code}
was (Author: jamezp):
If it helps too we could have a list of all the valid XML files on the base {{/deployment=*/subsystem=batch-jberet}} resource too.
{code}
{
"outcome" => "success",
"result" => {
"job-xml-files" => [
"simple.xml",
"retry-chunk.xml",
"partition-chunk.xml"
],
"job" => {
"simple" => {
"instance-count" => 0,
"job-xml-files" => ["simple.xml"],
"running-executions" => 0,
"execution" => undefined
},
"chunkPartition" => {
"instance-count" => 0,
"job-xml-files" => [
"retry-chunk.xml",
"partition-chunk.xml"
],
"running-executions" => 0,
"execution" => undefined
}
}
}
}
{code}
> read-resource should return the job file name
> ---------------------------------------------
>
> Key: WFLY-6858
> URL: https://issues.jboss.org/browse/WFLY-6858
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: Claudio Miranda
> Assignee: James Perkins
>
> The start-job operation must pass the job file name as parameter,
> /deployment=*/subsystem=batch-jberet:read-operation-description(name=start-job)
> however the jon attribute below, returns the job-id name, not the job file name
> /deployment=*/subsystem=batch-jberet/job=*
> So there is no way to know at runtime, the job file name. Is it possible to return the job xml file name ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6964) read-resource should return the job file name
by James Perkins (JIRA)
James Perkins created WFLY-6964:
-----------------------------------
Summary: read-resource should return the job file name
Key: WFLY-6964
URL: https://issues.jboss.org/browse/WFLY-6964
Project: WildFly
Issue Type: Bug
Components: Batch
Reporter: Claudio Miranda
Assignee: James Perkins
The start-job operation must pass the job file name as parameter,
/deployment=*/subsystem=batch-jberet:read-operation-description(name=start-job)
however the jon attribute below, returns the job-id name, not the job file name
/deployment=*/subsystem=batch-jberet/job=*
So there is no way to know at runtime, the job file name. Is it possible to return the job xml file name ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6858) read-resource should return the job file name
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6858?page=com.atlassian.jira.plugin.... ]
James Perkins edited comment on WFLY-6858 at 8/16/16 1:44 PM:
--------------------------------------------------------------
[~claudio4j] Would something like the following work?
{code}
{
"outcome" => "success",
"result" => {"job" => {
"simple" => {
"instance-count" => 0,
"job-xml-files" => ["simple.xml"],
"running-executions" => 0,
"execution" => undefined
},
"chunkPartition" => {
"instance-count" => 0,
"job-xml-names" => [
"retry-chunk.xml",
"partition-chunk.xml"
],
"running-executions" => 0,
"execution" => undefined
}
}}
}
{code}
The new attribute is {{job-xml-names}}.
was (Author: jamezp):
[~claudio4j] Would something like the following work?
{code}
{
"outcome" => "success",
"result" => {"job" => {
"simple" => {
"instance-count" => 0,
"job-xml-files" => ["simple.xml"],
"running-executions" => 0,
"execution" => undefined
},
"chunkPartition" => {
"instance-count" => 0,
"job-xml-files" => [
"retry-chunk.xml",
"partition-chunk.xml"
],
"running-executions" => 0,
"execution" => undefined
}
}}
}
{code}
The new attribute is {{job-xml-files}}.
> read-resource should return the job file name
> ---------------------------------------------
>
> Key: WFLY-6858
> URL: https://issues.jboss.org/browse/WFLY-6858
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Reporter: Claudio Miranda
> Assignee: James Perkins
>
> The start-job operation must pass the job file name as parameter,
> /deployment=*/subsystem=batch-jberet:read-operation-description(name=start-job)
> however the jon attribute below, returns the job-id name, not the job file name
> /deployment=*/subsystem=batch-jberet/job=*
> So there is no way to know at runtime, the job file name. Is it possible to return the job xml file name ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (WFLY-6882) A client is not able to invoke EJB's deployed as "HASingleton deployment"
by Enrique González Martínez (JIRA)
[ https://issues.jboss.org/browse/WFLY-6882?page=com.atlassian.jira.plugin.... ]
Enrique González Martínez commented on WFLY-6882:
-------------------------------------------------
[~pferraro] I understand the logic of how the system works and thanks for clarify this was by design (something I wasn't aware of). The problem (now I'm making a wild guess) is that the user does not want to lose the advantadge given by configuring just an entry point in the jboss-ejb-client properties and get the full topology (if you add more nodes... you don't need to redeploy anything).
I was trying to create aservice activator (to create a null service with that dependency https://issues.jboss.org/browse/JBEAP-5422?focusedCommentId=13279538&page...) for this sort of singleton deployment and it didn't work -maybe I did something wrong but only works in a separte jar (I haven't gone through that part of the code as singleton service has been rewritten).
Not sure if it would be possible to add a mechanism to this singleton deployments where you can set some dependencies that will start even if the ejb is not deployed. That would satisfy the behaviour by design and this special case where the user wants the full topology.
> A client is not able to invoke EJB's deployed as "HASingleton deployment"
> -------------------------------------------------------------------------
>
> Key: WFLY-6882
> URL: https://issues.jboss.org/browse/WFLY-6882
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Enrique González Martínez
>
> Given that an application contains a SLSB and is clustered, any EJB client will be updated to have a view off all cluster members and is able to use and failover to any node in the cluster no matter whether it is in the initial list of servers.
> Now if the application is marked as "singleton-deployment" via jboss-all.xml and deployed to all servers only one server in a cluster will pick it and make it active.
> Now the expectation is that a client is routed to that server no matter whether this special server is included in the clients initial connection list.
> The interesting thing is that the client.log show that both servers are connected it the application is NOT marked as singleton
> But only the initial server is connected if the app is marked as singleton!
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months