[JBoss JIRA] (WFLY-1629) LSB init script for Debian based distros
by Jorge Solorzano (JIRA)
[ https://issues.jboss.org/browse/WFLY-1629?page=com.atlassian.jira.plugin.... ]
Jorge Solorzano closed WFLY-1629.
---------------------------------
> LSB init script for Debian based distros
> ----------------------------------------
>
> Key: WFLY-1629
> URL: https://issues.jboss.org/browse/WFLY-1629
> Project: WildFly
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 8.0.0.Alpha1, 8.0.0.Alpha2, 8.0.0.Alpha3
> Environment: Debian/Ubuntu based
> Reporter: Jorge Solorzano
> Assignee: Brian Stansberry
> Priority: Minor
> Labels: Debian,, Ubuntu, init.d
> Fix For: 8.0.0.Alpha4
>
>
> init.d scripts provided by WildFly are designed for RedHat/Fedora, and it should provide a script that works well in Debian/Ubuntu based distributions.
> I could provide a LSB-compliant init script with all the features required for a complete startup script.
--
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, 9 months
[JBoss JIRA] (JBCLUSTER-300) Upgrade jboss-ha-server-core to use JGroup 3.x
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JBCLUSTER-300?page=com.atlassian.jira.plu... ]
Paul Ferraro closed JBCLUSTER-300.
----------------------------------
Resolution: Out of Date
The jboss-ha-server-core module is obsolete.
> Upgrade jboss-ha-server-core to use JGroup 3.x
> -----------------------------------------------
>
> Key: JBCLUSTER-300
> URL: https://issues.jboss.org/browse/JBCLUSTER-300
> Project: JBoss Clustering
> Issue Type: Component Upgrade
> Security Level: Public(Everyone can see)
> Components: HA-Server-Core
> Affects Versions: HA-Server-Core 1.0.0.Final
> Reporter: Rick Dong
> Assignee: Paul Ferraro
>
> JGroup 3.x is not backward compatible with its 2.x versions. This makes it difficult for projects that is using it and others such as HSearch and Infinispan to upgrade since HSearch 4.x and Infinispan 5.1.x have moved to 3.x while the cluster project is still on 2.x.
--
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, 9 months
[JBoss JIRA] (JBCLUSTER-303) [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (Incoming-4, null) Problems unmarshalling remote command from byte buffer: org.infinispan.CacheException: Type of data read is unknown. Id=85 is not amongst known reader indexes.
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JBCLUSTER-303?page=com.atlassian.jira.plu... ]
Paul Ferraro closed JBCLUSTER-303.
----------------------------------
Resolution: Out of Date
This module is obsolete.
> [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (Incoming-4,null) Problems unmarshalling remote command from byte buffer: org.infinispan.CacheException: Type of data read is unknown. Id=85 is not amongst known reader indexes.
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBCLUSTER-303
> URL: https://issues.jboss.org/browse/JBCLUSTER-303
> Project: JBoss Clustering
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: HA-Server-Cache-ISPN
> Environment: JBOSS 7.1.1 FINAL , REDHAT LINUX ENTERPRISE
> Reporter: pankaj pandey
> Assignee: Paul Ferraro
>
> I am getting problem while implementing jboss 7 clustering with session persistence.
> ava.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26] Caused by: an exception which occurred: in element at index [0] of size [1]
> 02:41:08,277 WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (Incoming-4,null) Problems unmarshalling remote command from byte buffer: org.infinispan.CacheException: Type of data read is unknown. Id=85 is not amongst known reader indexes. at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:216) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:180) at org.jboss.marshalling.river.RiverUnmarshaller.readCollectionData(RiverUnmarshaller.java:772) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:669) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37) [jboss-marshalling-1.3.14.GA-redhat-1.jar:1.3.14.GA-redhat-1] at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readParameters(ReplicableCommandExternalizer.java:119) at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readObject(ReplicableCommandExternalizer.java:107) at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readObject(ReplicableCommandExternalizer.java:58) at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:391) at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:222) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37) [jboss-marshalling-1.3.14.GA-redhat-1.jar:1.3.14.GA-redhat-1] at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readParameters(ReplicableCommandExternalizer.java:119) at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:163) at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:67) at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:391) at org.infinispan.marshall.jboss.ExternalizerTable.readObject(ExternalizerTable.java:222) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351) at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37) [jboss-marshalling-1.3.14.GA-redhat-1.jar:1.3.14.GA-redhat-1] at org.infinispan.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:154) at org.infinispan.marshall.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:114) at org.infinispan.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:85) at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:50) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:200) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:543) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.blocks.mux.MuxUpHandler.up(MuxUpHandler.java:130) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.JChannel.up(JChannel.java:716) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.RSVP.up(RSVP.java:192) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.FRAG2.up(FRAG2.java:181) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.FlowControl.up(FlowControl.java:400) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.FlowControl.up(FlowControl.java:418) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.pbcast.GMS.up(GMS.java:889) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:383) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:739) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:566) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.BARRIER.up(BARRIER.java:126) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.FD.up(FD.java:273) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.MERGE2.up(MERGE2.java:205) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.Discovery.up(Discovery.java:359) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.stack.Protocol.up(Protocol.java:363) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.TP.passMessageUp(TP.java:1180) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1728) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1710) [jgroups-3.0.9.Final-redhat-1.jar:3.0.9.Final-redhat-1] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_26] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_26] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_26] Caused by: an exception which occurred: in element at index [0] of size [1]
--
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, 9 months
[JBoss JIRA] (WFLY-1790) RBAC: HostScopedRole* operations are wrong (copy&paste from ServerGroupScopedRole*)
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFLY-1790?page=com.atlassian.jira.plugin.... ]
Ladislav Thon commented on WFLY-1790:
-------------------------------------
This is a current issue, not a retrospective one.
I have a naive fix for this locally that I can share.
> RBAC: HostScopedRole* operations are wrong (copy&paste from ServerGroupScopedRole*)
> -----------------------------------------------------------------------------------
>
> Key: WFLY-1790
> URL: https://issues.jboss.org/browse/WFLY-1790
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
>
> This is the issue I was speaking about with Brian yesterday.
> The {{HostScopedRole*}} operations are clearly a copy&paste from {{ServerGroupScopedRole*}} operations. Sadly, there are few artifacts of this:
> - {{HostScopedRoleAdd.performRuntime}} refers to attribute definitions from {{ServerGroupScopedRoleResourceDefinition}}, while it should use the ones from {{HostScopedRolesResourceDefinition}}
> - all the {{HostScopedRoleAdd}}, {{HostScopedRoleRemove}} and {{HostScopedRoleWriteAttributeHandler}} operations expect that the {{hosts}} attribute will always contain a valid list, while it can easily be undefined (see {{HostScopedRolesResourceDefinition.HOSTS}})
--
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, 9 months
[JBoss JIRA] (WFLY-1790) RBAC: HostScopedRole* operations are wrong (copy&paste from ServerGroupScopedRole*)
by Ladislav Thon (JIRA)
Ladislav Thon created WFLY-1790:
-----------------------------------
Summary: RBAC: HostScopedRole* operations are wrong (copy&paste from ServerGroupScopedRole*)
Key: WFLY-1790
URL: https://issues.jboss.org/browse/WFLY-1790
Project: WildFly
Issue Type: Feature Request
Components: Domain Management
Reporter: Ladislav Thon
Assignee: Brian Stansberry
This is the issue I was speaking about with Brian yesterday.
The {{HostScopedRole*}} operations are clearly a copy&paste from {{ServerGroupScopedRole*}} operations. Sadly, there are few artifacts of this:
- {{HostScopedRoleAdd.performRuntime}} refers to attribute definitions from {{ServerGroupScopedRoleResourceDefinition}}, while it should use the ones from {{HostScopedRolesResourceDefinition}}
- all the {{HostScopedRoleAdd}}, {{HostScopedRoleRemove}} and {{HostScopedRoleWriteAttributeHandler}} operations expect that the {{hosts}} attribute will always contain a valid list, while it can easily be undefined (see {{HostScopedRolesResourceDefinition.HOSTS}})
--
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, 9 months
[JBoss JIRA] (WFLY-1789) RBAC: OperationContextImpl.readResourceForUpdate is missing an authorize call
by Ladislav Thon (JIRA)
Ladislav Thon created WFLY-1789:
-----------------------------------
Summary: RBAC: OperationContextImpl.readResourceForUpdate is missing an authorize call
Key: WFLY-1789
URL: https://issues.jboss.org/browse/WFLY-1789
Project: WildFly
Issue Type: Feature Request
Components: Domain Management
Reporter: Ladislav Thon
Assignee: Brian Stansberry
[This issue was in fact found on 2013-07-09 and is being filled now only for tracking purposes.]
During code inspection, I found one method in the {{OperationContextImpl}} class that is IMHO missing an {{authorize}} call: {{readResourceForUpdate}}. Compare with {{readModelForUpdate}}. See TODO in the code.
--
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, 9 months
[JBoss JIRA] (WFLY-1789) RBAC: OperationContextImpl.readResourceForUpdate is missing an authorize call
by Ladislav Thon (JIRA)
[ https://issues.jboss.org/browse/WFLY-1789?page=com.atlassian.jira.plugin.... ]
Ladislav Thon commented on WFLY-1789:
-------------------------------------
I remember discussing this with Brian, but I see that the TODO is still in the code. So I'm leaving this open and assigned to Brian.
> RBAC: OperationContextImpl.readResourceForUpdate is missing an authorize call
> -----------------------------------------------------------------------------
>
> Key: WFLY-1789
> URL: https://issues.jboss.org/browse/WFLY-1789
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
>
> [This issue was in fact found on 2013-07-09 and is being filled now only for tracking purposes.]
> During code inspection, I found one method in the {{OperationContextImpl}} class that is IMHO missing an {{authorize}} call: {{readResourceForUpdate}}. Compare with {{readModelForUpdate}}. See TODO in the code.
--
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, 9 months