August 2016 - jboss-jira - Jboss List Archives

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFCORE-1429) Add property to skip LogManager check at startup

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1429?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-1429: --------------------------------------- One thing to note about wrapping the log manager. If JBoss Logging will use the JUL provider instead of the JBoss Log Manager provider. That means things like MDC and NDC will behave differently and likely not be usable when writing log messages. > Add property to skip LogManager check at startup > ------------------------------------------------ > > Key: WFCORE-1429 > URL: https://issues.jboss.org/browse/WFCORE-1429 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: Dominique Broeglin > Assignee: James Perkins > Priority: Minor > Fix For: 3.0.0.Alpha6 > > > At startup, Wildfly checks that the default log manager (as returned by {{java.util.logging.LogManager.getLogManager()}} ) is {{org.jboss.logmanager.LogManager}}: > https://github.com/wildfly/wildfly-core/blob/master/logging/src/main/java... > This breaks some cases where the LogManager is wrapped because of the needs of that particular JVM like in OSv ( https://github.com/cloudius-systems/osv/blob/master/java/runjava/src/main... ). > As suggested on the mailing list, I would like to propose adding a property to bypass that check. Something along the lines of "jboss.logging.logManagerCheck = false/true" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6962) Upgrade MyFaces from 2.1.7 to 2.2.10

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/WFLY-6962?page=com.atlassian.jira.plugin.... ] Farah Juma reassigned WFLY-6962: -------------------------------- Assignee: Dmitrii Tikhomirov (was: Farah Juma) > Upgrade MyFaces from 2.1.7 to 2.2.10 > ------------------------------------ > > Key: WFLY-6962 > URL: https://issues.jboss.org/browse/WFLY-6962 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 10.1.0.CR1 > Reporter: Dmitrii Tikhomirov > Assignee: Dmitrii Tikhomirov > Priority: Critical > Fix For: 11.0.0.CR1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 8 months

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[JBoss JIRA] (WFLY-6964) read-resource should return the job file name

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-6964?page=com.atlassian.jira.plugin.... ] James Perkins updated WFLY-6964: -------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/9129) > 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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2016