May 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4575) Use Flag.RESTART_RESOURCE_SERVICES for child resources of stack/channel

by Paul Ferraro (JIRA)

Paul Ferraro created WFLY-4575: ---------------------------------- Summary: Use Flag.RESTART_RESOURCE_SERVICES for child resources of stack/channel Key: WFLY-4575 URL: https://issues.jboss.org/browse/WFLY-4575 Project: WildFly Issue Type: Enhancement Components: Clustering Affects Versions: 9.0.0.Alpha1 Reporter: Paul Ferraro Assignee: Paul Ferraro Currently, the attributes for each child resource of a cache use RESTART_ALL_SERVICES, thus any change to one of these attributes requires all services to restart. This is overkill, since only the services of the parent resource (i.e. cache) actually require restarting. Ideally, each child resource should create a runtime service for its corresponding sub-configuration. e.g. the transaction resource would create a Service<TransactionConfiguration>. Thus the cache resource's add handler becomes much less complex - and the corresponding Service<Configuration> need only depend on the sub-configuration services for each child resource. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4575) Use Flag.RESTART_RESOURCE_SERVICES for child resources of stack/channel

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-4575?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-4575: ------------------------------- Description: Currently, the attributes for each child resource of a stack or channel use RESTART_ALL_SERVICES, thus any change to one of these attributes requires all services to restart. This is overkill, since only the services of the parent resource (i.e. channel, channel factory) actually require restarting. (was: Currently, the attributes for each child resource of a cache use RESTART_ALL_SERVICES, thus any change to one of these attributes requires all services to restart. This is overkill, since only the services of the parent resource (i.e. cache) actually require restarting. Ideally, each child resource should create a runtime service for its corresponding sub-configuration. e.g. the transaction resource would create a Service<TransactionConfiguration>. Thus the cache resource's add handler becomes much less complex - and the corresponding Service<Configuration> need only depend on the sub-configuration services for each child resource.) > Use Flag.RESTART_RESOURCE_SERVICES for child resources of stack/channel > ----------------------------------------------------------------------- > > Key: WFLY-4575 > URL: https://issues.jboss.org/browse/WFLY-4575 > Project: WildFly > Issue Type: Enhancement > Components: Clustering > Affects Versions: 9.0.0.Alpha1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > > Currently, the attributes for each child resource of a stack or channel use RESTART_ALL_SERVICES, thus any change to one of these attributes requires all services to restart. This is overkill, since only the services of the parent resource (i.e. channel, channel factory) actually require restarting. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1264) NullPointerException hides cause of PostgreSql Exception for getConnection call.

by Jeremy Whiting (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1264?page=com.atlassian.jira.plugin... ] Jeremy Whiting closed JBJCA-1264. --------------------------------- Fix Version/s: 1.0.32.Final Resolution: Done Fixed in release ironjacamar-1.0.32.Final. > NullPointerException hides cause of PostgreSql Exception for getConnection call. > -------------------------------------------------------------------------------- > > Key: JBJCA-1264 > URL: https://issues.jboss.org/browse/JBJCA-1264 > Project: IronJacamar > Issue Type: Bug > Components: Core > Affects Versions: 1.0.30.Final > Environment: All environments. > Reporter: Jeremy Whiting > Assignee: Jesper Pedersen > Labels: nullPointerException, pgsqlexception > Fix For: 1.0.32.Final > > > When a datasource using PostgreSql is configured with the "loglevel" property the JCA db server causes a PGSqlException. Besides that cause the exception is not displayed to the user. > org.postgresql.util.PSQLException: Connection to localhost:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections. > The JCA code attempts to handle the exception in a catch block. Initially by logging a message. But the JCA code to log the message assumes the clw reference is not null. On this line > https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.0.30.Final/... > In my case clw is null. Which then causes an NullPointerException. Completely hiding the underlying exception to the user. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1264) NullPointerException hides cause of PostgreSql Exception for getConnection call.

by Jeremy Whiting (JIRA)

Jeremy Whiting created JBJCA-1264: ------------------------------------- Summary: NullPointerException hides cause of PostgreSql Exception for getConnection call. Key: JBJCA-1264 URL: https://issues.jboss.org/browse/JBJCA-1264 Project: IronJacamar Issue Type: Bug Components: Core Affects Versions: 1.0.30.Final Environment: All environments. Reporter: Jeremy Whiting Assignee: Jesper Pedersen When a datasource using PostgreSql is configured with the "loglevel" property the JCA db server causes a PGSqlException. Besides that cause the exception is not displayed to the user. org.postgresql.util.PSQLException: Connection to localhost:5432 refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections. The JCA code attempts to handle the exception in a catch block. Initially by logging a message. But the JCA code to log the message assumes the clw reference is not null. On this line https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.0.30.Final/... In my case clw is null. Which then causes an NullPointerException. Completely hiding the underlying exception to the user. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4574) Upgrade Mojarra to 2.2.11

by Cody Lerum (JIRA)

[ https://issues.jboss.org/browse/WFLY-4574?page=com.atlassian.jira.plugin.... ] Cody Lerum commented on WFLY-4574: ---------------------------------- https://java.net/jira/browse/JAVASERVERFACES-3855 is also an issue for Richfaces > Upgrade Mojarra to 2.2.11 > ------------------------- > > Key: WFLY-4574 > URL: https://issues.jboss.org/browse/WFLY-4574 > Project: WildFly > Issue Type: Component Upgrade > Components: JSF > Reporter: Cody Lerum > Assignee: Farah Juma > Fix For: 9.0.0.CR1 > > > Mojarra 2.2 now appears to be on a 4-6 month release cycle for 2.2.x and 2.2.11 is due for release on May 5th. https://java.net/jira/browse/JAVASERVERFACES/fixforversion/17193/?selecte... > It would be great if we could get this updated before 9.1.0.Final. > https://java.net/jira/browse/JAVASERVERFACES-3848 for example would be nice to pick up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4574) Upgrade Mojarra to 2.2.11

by Cody Lerum (JIRA)

[ https://issues.jboss.org/browse/WFLY-4574?page=com.atlassian.jira.plugin.... ] Cody Lerum updated WFLY-4574: ----------------------------- Description: Mojarra 2.2 now appears to be on a 4-6 month release cycle for 2.2.x and 2.2.11 is due for release on May 5th. https://java.net/jira/browse/JAVASERVERFACES/fixforversion/17193/?selecte... It would be great if we could get this updated before 9.1.0.Final. https://java.net/jira/browse/JAVASERVERFACES-3848 for example would be nice to pick up. was: Mojarra 2.2 now appears to be on a 4-6 month release cycle and 2.2.11 is due for release on May 5th. https://java.net/jira/browse/JAVASERVERFACES/fixforversion/17193/?selecte... It would be great if we could get this updated before 9.1.0.Final. https://java.net/jira/browse/JAVASERVERFACES-3848 for example would be nice to pick up. > Upgrade Mojarra to 2.2.11 > ------------------------- > > Key: WFLY-4574 > URL: https://issues.jboss.org/browse/WFLY-4574 > Project: WildFly > Issue Type: Component Upgrade > Components: JSF > Reporter: Cody Lerum > Assignee: Farah Juma > Fix For: 9.0.0.CR1 > > > Mojarra 2.2 now appears to be on a 4-6 month release cycle for 2.2.x and 2.2.11 is due for release on May 5th. https://java.net/jira/browse/JAVASERVERFACES/fixforversion/17193/?selecte... > It would be great if we could get this updated before 9.1.0.Final. > https://java.net/jira/browse/JAVASERVERFACES-3848 for example would be nice to pick up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4574) Upgrade Mojarra to 2.2.11

by Cody Lerum (JIRA)

Cody Lerum created WFLY-4574: -------------------------------- Summary: Upgrade Mojarra to 2.2.11 Key: WFLY-4574 URL: https://issues.jboss.org/browse/WFLY-4574 Project: WildFly Issue Type: Component Upgrade Components: JSF Reporter: Cody Lerum Assignee: Farah Juma Fix For: 9.0.0.CR1 Mojarra 2.2 now appears to be on a 4-6 month release cycle and 2.2.11 is due for release on May 5th. https://java.net/jira/browse/JAVASERVERFACES/fixforversion/17193/?selecte... It would be great if we could get this updated before 9.1.0.Final. https://java.net/jira/browse/JAVASERVERFACES-3848 for example would be nice to pick up. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4571) Merge the wildfly BOMs into a single BOM

by Paul Gier (JIRA)

[ https://issues.jboss.org/browse/WFLY-4571?page=com.atlassian.jira.plugin.... ] Paul Gier commented on WFLY-4571: --------------------------------- I updated the PR to retain the separate tools BOM. For both the hibernate3 and tools BOM, they now inherit from the main bom so they also include all of it's dependency management. I think it's a bit better this way so that you normally don't need to import more than one BOM. > Merge the wildfly BOMs into a single BOM > ---------------------------------------- > > Key: WFLY-4571 > URL: https://issues.jboss.org/browse/WFLY-4571 > Project: WildFly > Issue Type: Enhancement > Reporter: Paul Gier > Assignee: Paul Gier > > We had some discussion on the jbossdeveloper list [1] about merging the current wildfly/eap boms into a single one instead of a separate bom for each use case. > The only problematic BOM might be the hibernate3 bom because this includes dependencies which conflict with the hibernate 4 bom. So the hibernate 3 bom will probably need to remain separate. > [1]http://lists.jboss.org/pipermail/jbossdeveloper/2015-April/000347.html -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-670) Node type is not complete at index 0 after tab completion on an empty resource

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-670?page=com.atlassian.jira.plugin... ] James Perkins commented on WFCORE-670: -------------------------------------- I added a blocker flag, but IMO it just needs to be fixed by 1.0.0.Final. > Node type is not complete at index 0 after tab completion on an empty resource > ------------------------------------------------------------------------------ > > Key: WFCORE-670 > URL: https://issues.jboss.org/browse/WFCORE-670 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: James Perkins > Assignee: Alexey Loubyansky > Priority: Blocker > Fix For: 1.0.0.CR1 > > > Using something like {{/system-property=<TAB>}} with no system properties set results in future commands no longer working. > {code:title=Example Output} > [standalone@localhost:9990 /] /system-property= > The operation name is missing or the format of the operation request is wrong. > [standalone@localhost:9990 /] > [standalone@localhost:9990 /] exit > Node type is not complete at index 0 > [standalone@localhost:9990 /] > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-670) Node type is not complete at index 0 after tab completion on an empty resource

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-670?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-670: --------------------------------- Priority: Blocker (was: Major) > Node type is not complete at index 0 after tab completion on an empty resource > ------------------------------------------------------------------------------ > > Key: WFCORE-670 > URL: https://issues.jboss.org/browse/WFCORE-670 > Project: WildFly Core > Issue Type: Bug > Components: CLI > Reporter: James Perkins > Assignee: Alexey Loubyansky > Priority: Blocker > Fix For: 1.0.0.CR1 > > > Using something like {{/system-property=<TAB>}} with no system properties set results in future commands no longer working. > {code:title=Example Output} > [standalone@localhost:9990 /] /system-property= > The operation name is missing or the format of the operation request is wrong. > [standalone@localhost:9990 /] > [standalone@localhost:9990 /] exit > Node type is not complete at index 0 > [standalone@localhost:9990 /] > {code} -- This message was sent by Atlassian JIRA (v6.3.15#6346)

11 years, 2 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 May 2015