November 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-1727) McastReceiverTest output does not display correctly on Windows

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1727?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz resolved JGRP-1727. --------------------------------------- Resolution: Done > McastReceiverTest output does not display correctly on Windows > -------------------------------------------------------------- > > Key: JGRP-1727 > URL: https://issues.jboss.org/browse/JGRP-1727 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.5 > Environment: Windows XP, Windows 7 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Minor > Fix For: 3.5 > > > When using McastSenderTest and McastReceiverTest on Windows to check multicast connectivity, the output displayed by McastReceiverTest not presented in the same was as when running the utilities on Linux; part of the output is either completely lost (Windows 7) or the output has extra blank characters inserted (Windows XP). > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1727) McastReceiverTest output does not display correctly on Windows

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1727?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz reassigned JGRP-1727: ----------------------------------------- Assignee: Richard Achmatowicz (was: Bela Ban) > McastReceiverTest output does not display correctly on Windows > -------------------------------------------------------------- > > Key: JGRP-1727 > URL: https://issues.jboss.org/browse/JGRP-1727 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.5 > Environment: Windows XP, Windows 7 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Minor > Fix For: 3.5 > > > When using McastSenderTest and McastReceiverTest on Windows to check multicast connectivity, the output displayed by McastReceiverTest not presented in the same was as when running the utilities on Linux; part of the output is either completely lost (Windows 7) or the output has extra blank characters inserted (Windows XP). > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1727) McastReceiverTest output does not display correctly on Windows

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/JGRP-1727?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on JGRP-1727: ------------------------------------------- The problem is is the following: when a DatagramPacket is received by McastReceiverTest, a String used for display of the payload is created as follows: {noformat} new String(packet.getData()) {noformat} where the size of the array returned by DatagramPacket.getData() is fixed at 256. Any data in the buffer is followed by zeros. On Linux, this seems to work fine to create the right String; on Windows, the String created contains the trailing zeros and the display gets messed up. This can be fixed as follows: {noformat} new String(packet.getData(), 0, packet.getLength()) {noformat} > McastReceiverTest output does not display correctly on Windows > -------------------------------------------------------------- > > Key: JGRP-1727 > URL: https://issues.jboss.org/browse/JGRP-1727 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.5 > Environment: Windows XP, Windows 7 > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > When using McastSenderTest and McastReceiverTest on Windows to check multicast connectivity, the output displayed by McastReceiverTest not presented in the same was as when running the utilities on Linux; part of the output is either completely lost (Windows 7) or the output has extra blank characters inserted (Windows XP). > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2422) Simplify the remote-outbound connections

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-2422?page=com.atlassian.jira.plugin.... ] David Lloyd reassigned WFLY-2422: --------------------------------- Assignee: Cheng Fang (was: David Lloyd) Cheng, I was wondering if you might be interested in looking at this one. > Simplify the remote-outbound connections > ---------------------------------------- > > Key: WFLY-2422 > URL: https://issues.jboss.org/browse/WFLY-2422 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: EJB, Remoting > Affects Versions: 8.0.0.Beta1 > Reporter: Wolf-Dieter Fink > Assignee: Cheng Fang > > At the moment the application need to reference each outbound connection with a remote-ejb-receiver element in the jboss-ejb-client.xml. > But from an application perspective it is not relevant whether the server environment provide one or many receivers or whether the ejb-receiver is a cluster. > It should be possible to add many outbound-socket-binding-ref elements and related properties to the remote-outbound-connection element of the server configuration. > In this case it is possible to keep the application deployment independent from the server environment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2422) Simplify the remote-outbound connections

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFLY-2422?page=com.atlassian.jira.plugin.... ] David Lloyd commented on WFLY-2422: ----------------------------------- *Requirements* (edit as needed) Essentially this implies that the EJB subsystem will have to become aware of the deployment EJB client context. We should have a sort of "client context profile" notion in the EJB subsystem configuration. Then jboss-ejb-client.xml can simply select a profile (and possibly supplement it with more direct connection information). The EJB client context profile should contain a listing of discovery methods, though to start we'd only support one: static connection listing. Deployments with a given selected profile will have those EJB receivers registered with the deployment EJB client context. > Simplify the remote-outbound connections > ---------------------------------------- > > Key: WFLY-2422 > URL: https://issues.jboss.org/browse/WFLY-2422 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: EJB, Remoting > Affects Versions: 8.0.0.Beta1 > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > > At the moment the application need to reference each outbound connection with a remote-ejb-receiver element in the jboss-ejb-client.xml. > But from an application perspective it is not relevant whether the server environment provide one or many receivers or whether the ejb-receiver is a cluster. > It should be possible to add many outbound-socket-binding-ref elements and related properties to the remote-outbound-connection element of the server configuration. > In this case it is possible to keep the application deployment independent from the server environment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1727) McastReceiverTest output does not display correctly on Windows

by Richard Achmatowicz (JIRA)

Richard Achmatowicz created JGRP-1727: ----------------------------------------- Summary: McastReceiverTest output does not display correctly on Windows Key: JGRP-1727 URL: https://issues.jboss.org/browse/JGRP-1727 Project: JGroups Issue Type: Bug Affects Versions: 3.5 Environment: Windows XP, Windows 7 Reporter: Richard Achmatowicz Assignee: Bela Ban Priority: Minor Fix For: 3.5 When using McastSenderTest and McastReceiverTest on Windows to check multicast connectivity, the output displayed by McastReceiverTest not presented in the same was as when running the utilities on Linux; part of the output is either completely lost (Windows 7) or the output has extra blank characters inserted (Windows XP). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-1982?page=com.atlassian.jira.plugin.... ] Emanuel Muckenhuber resolved WFLY-1982. --------------------------------------- Resolution: Done > NPE in ModelControllerLock > -------------------------- > > Key: WFLY-1982 > URL: https://issues.jboss.org/browse/WFLY-1982 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.CR1 > > > Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase: > 22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException > at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15] > at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148) > at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899) > at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282) > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2411) SecurityRealm authentication does not get marshalled when empty

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-2411?page=com.atlassian.jira.plugin.... ] Emanuel Muckenhuber resolved WFLY-2411. --------------------------------------- Resolution: Done > SecurityRealm authentication does not get marshalled when empty > --------------------------------------------------------------- > > Key: WFLY-2411 > URL: https://issues.jboss.org/browse/WFLY-2411 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Beta1 > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.CR1 > > > The /core-service=management/security-realm=ManagementRealm/authentication=users resource does not get persisted in case it does not contain any users. This causes problems since the resource is not restored after a reload or restart of the server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2410) composite operation containing a host op does not get rolled out to all hosts

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-2410?page=com.atlassian.jira.plugin.... ] Emanuel Muckenhuber resolved WFLY-2410. --------------------------------------- Resolution: Done > composite operation containing a host op does not get rolled out to all hosts > ----------------------------------------------------------------------------- > > Key: WFLY-2410 > URL: https://issues.jboss.org/browse/WFLY-2410 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.0.0.Beta1 > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.CR1 > > > If a composite operation contains an operation targeting the domain as well as a single host, it will only get rolled out to the host specified rather than to the complete domain. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-364) a "failure-causes-rollback="false"" attribute for the filesystem scanner

by Emanuel Muckenhuber (JIRA)

[ https://issues.jboss.org/browse/WFLY-364?page=com.atlassian.jira.plugin.s... ] Emanuel Muckenhuber reassigned WFLY-364: ---------------------------------------- Assignee: Emanuel Muckenhuber (was: Brian Stansberry) > a "failure-causes-rollback="false"" attribute for the filesystem scanner > ------------------------------------------------------------------------ > > Key: WFLY-364 > URL: https://issues.jboss.org/browse/WFLY-364 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Max Rydahl Andersen > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.CR1 > > > JBIDE-11509, AS7-783 and TORQUE-576 all talk about the problem of all deployments found at startup is deployed in one operation and if one deployment fails all is rolled back resulting in some rather bad usability issues - especially at development time, but even also at production time for those using file deployments. > Suggestion on irc was that there could be an option on the file scanner (possibly false by default?) to say that failure causes rollback. > Individual deployments could then still fail, but at least not everything would be rolledback and it would still allow proper interdependent deployments to work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 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 November 2013