September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-6245) ClassNotFoundException if CMP2 entity-command is used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/AS7-6245?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on AS7-6245: ---------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 901279|https://bugzilla.redhat.com/show_bug.cgi?id=901279] from POST to MODIFIED > ClassNotFoundException if CMP2 entity-command is used > ----------------------------------------------------- > > Key: AS7-6245 > URL: https://issues.jboss.org/browse/AS7-6245 > Project: Application Server 7 > Issue Type: Bug > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Labels: cmp, ejb2 > Fix For: EAP 6.1.0.Alpha (7.2.0.Final), 7.1.4.Final (EAP) > > > If a EJB2 - CMP2 EntityBean uses an entity-command 'mysql-get-generated-keys' to generate the primary key, the server deploy with an error message: > Caused by: java.lang.RuntimeException: JBAS018572: Could not load driver class: com.mysql.jdbc.PreparedStatement > This may happen for different entity-commands if other databases are used! > If the datasource module is added to the org/jboss/as/cmp modules dependencies, the startup shows: > MSC000001: Failed to start service ... : JBAS010785: Failed start store manager > Caused by: java.lang.RuntimeException: JBAS010732: Couldn't create entity command > Caused by: java.lang.RuntimeException: JBAS018574: Could not load org.jboss.resource.adapter.jdbc.StatementAccess -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-83) EAR deployment overlay did not work if there is no related resource included in the ear

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-83?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFCORE-83: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1145364|https://bugzilla.redhat.com/show_bug.cgi?id=1145364] from POST to MODIFIED > EAR deployment overlay did not work if there is no related resource included in the ear > --------------------------------------------------------------------------------------- > > Key: WFCORE-83 > URL: https://issues.jboss.org/browse/WFCORE-83 > Project: WildFly Core > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Stuart Douglas > Fix For: 1.0.0.Alpha6 > > Attachments: reproducer.zip > > > It is possible to overlay WEB-inf/lib/xy.jar without having xy.jar included in the war file. > If an EAR file is used a module in the lib directory can not be added in the same way. But overlay is working if the lib/xy.jar is available. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-46) Fix intermittent failures in DeploymentOverlayCLITestCase

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-46?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFCORE-46: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1144222|https://bugzilla.redhat.com/show_bug.cgi?id=1144222] from POST to MODIFIED > Fix intermittent failures in DeploymentOverlayCLITestCase > --------------------------------------------------------- > > Key: WFCORE-46 > URL: https://issues.jboss.org/browse/WFCORE-46 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha4 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 1.0.0.Alpha9 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-82) Defining a HTTP management interface with secure-port or https socket binding but not security realm causes NullPointerException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-82?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFCORE-82: ----------------------------------------------- Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 908236|https://bugzilla.redhat.com/show_bug.cgi?id=908236] from ON_QA to VERIFIED > Defining a HTTP management interface with secure-port or https socket binding but not security realm causes NullPointerException > -------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-82 > URL: https://issues.jboss.org/browse/WFCORE-82 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 1.0.0.Alpha5 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha6 > > > There are actually two checks that need to be performed: - > 1 - If a secure port is required then a security realm must be associated with the interface. > 2 - That security realm must supply an SSLContext > For #1 that can at least be validated in the model at the end of stage MODEL. This will need to be validated for both standalone mode and domain mode - each of these use independent resource definitions. > #2 will have to wait until RUNTIME where we have the opportunity to check that the injected realm does supply a SSLContext. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2964) Missing i18n

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2964?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2964: ----------------------------------------------- Nikoleta Ziakova <nziakova(a)redhat.com> changed the Status of [bug 1067024|https://bugzilla.redhat.com/show_bug.cgi?id=1067024] from ON_QA to VERIFIED > Missing i18n > ------------ > > Key: WFLY-2964 > URL: https://issues.jboss.org/browse/WFLY-2964 > Project: WildFly > Issue Type: Bug > Components: EJB, JMX, Patching > Affects Versions: 8.0.0.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 9.0.0.Alpha1 > > > system-jmx/src/main/java/org/jboss/system/ServiceMBeanSupport.java > 379 log.error(e); > patching/src/main/java/org/jboss/as/patching/validation/PatchArtifact.java > 102 ctx.getErrorHandler().error("Failed to load identity info for patch " + patch.getPatchId(), e); > 116 ctx.getErrorHandler().error("Failed to load previous patch", e); > patching/src/main/java/org/jboss/as/patching/validation/XmlFileState.java > 51 ctx.getErrorHandler().error("File doesn't exist: " + file.getAbsolutePath()); > 56 ctx.getErrorHandler().error("Failed to parse file: " + file.getAbsolutePath(), e); > patching/src/main/java/org/jboss/as/patching/validation/PatchElementProviderArtifact.java > 84 ctx.getErrorHandler().error("Layer not found: " + metadata.getName()); > patching/src/main/java/org/jboss/as/patching/runner/IdentityPatchContext.java > 435 PatchLogger.ROOT_LOGGER.warnf(e, "failed to undo change (%s)", modification); > ejb3/src/main/java/org/jboss/as/ejb3/tx/CMTTxInterceptor.java > 169 EjbLogger.ROOT_LOGGER.error(t); -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-46) Fix intermittent failures in DeploymentOverlayCLITestCase

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-46?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFCORE-46: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1144222|https://bugzilla.redhat.com/show_bug.cgi?id=1144222] from NEW to POST > Fix intermittent failures in DeploymentOverlayCLITestCase > --------------------------------------------------------- > > Key: WFCORE-46 > URL: https://issues.jboss.org/browse/WFCORE-46 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha4 > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 1.0.0.Alpha9 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-83) EAR deployment overlay did not work if there is no related resource included in the ear

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-83?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFCORE-83: ----------------------------------------------- Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1145364|https://bugzilla.redhat.com/show_bug.cgi?id=1145364] from NEW to POST > EAR deployment overlay did not work if there is no related resource included in the ear > --------------------------------------------------------------------------------------- > > Key: WFCORE-83 > URL: https://issues.jboss.org/browse/WFCORE-83 > Project: WildFly Core > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Stuart Douglas > Fix For: 1.0.0.Alpha6 > > Attachments: reproducer.zip > > > It is possible to overlay WEB-inf/lib/xy.jar without having xy.jar included in the war file. > If an EAR file is used a module in the lib directory can not be added in the same way. But overlay is working if the lib/xy.jar is available. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1851) RSVP: add option to not block caller

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1851?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1851 at 9/26/14 4:50 AM: --------------------------------------------------------- We could also add a check for UNICAST3 and ignore RSVP handling for unicasts if UNICAST3 is present, as UNICAST3 does resend messages itself. This essentially makes RSVP only needed by NAKACK2 (and UNICAST2, but this is deprecated anyway). was (Author: belaban): We could also add a check for UNICAST3 and ignore RSVP handling for unicasts if UNICAST3 is present, as UNICAST3 does resend messages itself. > RSVP: add option to not block caller > ------------------------------------ > > Key: JGRP-1851 > URL: https://issues.jboss.org/browse/JGRP-1851 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6 > > > In RSVP we have a {{resend_interval}} at which empty messages are sent to trigger retransmission and a {{timeout}} which is the max time a caller will block until all acks have been received. > In the {{down()}} method, the caller blocks until all acks have been received or a timeout occured. Then the resend task is stopped and the entry removed from the {{ids}} map. > In some cases, we may want to not block the caller, so that the calling thread returns immediately, but nevertheless perform resending until all acks have been received or the timeout occurred. This is a new property {{block}}. > An example of where this is useful is {{RpcDispatcher.callRemoteMethodsWithFuture()}}: here, we want the call to return immediately with a future, and then - later - potentially block on it. However, if we have the RSVP flag set, then sending the message will block in RSVP until all acks have been received. This breaks the semantics of {{callRemoteMethodsWithFuture()}}. > Another example is async RPCs (mode={{GET_NONE}}); here we'd block if RSVP is set even though we shouldn't. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1851) RSVP: add option to not block caller

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1851?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1851: -------------------------------- We could also add a check for UNICAST3 and ignore RSVP handling for unicasts if UNICAST3 is present, as UNICAST3 does resend messages itself. > RSVP: add option to not block caller > ------------------------------------ > > Key: JGRP-1851 > URL: https://issues.jboss.org/browse/JGRP-1851 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6 > > > In RSVP we have a {{resend_interval}} at which empty messages are sent to trigger retransmission and a {{timeout}} which is the max time a caller will block until all acks have been received. > In the {{down()}} method, the caller blocks until all acks have been received or a timeout occured. Then the resend task is stopped and the entry removed from the {{ids}} map. > In some cases, we may want to not block the caller, so that the calling thread returns immediately, but nevertheless perform resending until all acks have been received or the timeout occurred. This is a new property {{block}}. > An example of where this is useful is {{RpcDispatcher.callRemoteMethodsWithFuture()}}: here, we want the call to return immediately with a future, and then - later - potentially block on it. However, if we have the RSVP flag set, then sending the message will block in RSVP until all acks have been received. This breaks the semantics of {{callRemoteMethodsWithFuture()}}. > Another example is async RPCs (mode={{GET_NONE}}); here we'd block if RSVP is set even though we shouldn't. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1851) RSVP: add option to not block caller

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1851?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1851: -------------------------------- An unrelated improvement is to have a single resend task which sends beacon messages for all pending messages, rather than _1 task per pending message_. Also, if we have 5 unacked *multicast* messages (dest==null), then we could send *1 beacon message rather than 5* ! This would reduce the number of beacon messages to be sent and the number of tasks needed for those. > RSVP: add option to not block caller > ------------------------------------ > > Key: JGRP-1851 > URL: https://issues.jboss.org/browse/JGRP-1851 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6 > > > In RSVP we have a {{resend_interval}} at which empty messages are sent to trigger retransmission and a {{timeout}} which is the max time a caller will block until all acks have been received. > In the {{down()}} method, the caller blocks until all acks have been received or a timeout occured. Then the resend task is stopped and the entry removed from the {{ids}} map. > In some cases, we may want to not block the caller, so that the calling thread returns immediately, but nevertheless perform resending until all acks have been received or the timeout occurred. This is a new property {{block}}. > An example of where this is useful is {{RpcDispatcher.callRemoteMethodsWithFuture()}}: here, we want the call to return immediately with a future, and then - later - potentially block on it. However, if we have the RSVP flag set, then sending the message will block in RSVP until all acks have been received. This breaks the semantics of {{callRemoteMethodsWithFuture()}}. > Another example is async RPCs (mode={{GET_NONE}}); here we'd block if RSVP is set even though we shouldn't. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2014