November 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8679) Add xml comment support to the domain model

by Jason Greene (JIRA)

Add xml comment support to the domain model ------------------------------------------- Key: JBAS-8679 URL: https://jira.jboss.org/browse/JBAS-8679 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Jason Greene Fix For: 7.0.0.Beta1 For usability reasons, we should attach an xml comment to the nearest AbstractModelElement, so that they can be recreated when the model is altered. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

4
5
0 / 0

[JBoss JIRA] Created: (JBAS-8140) Standard JTS-based configuration

by Brian Stansberry (JIRA)

Standard JTS-based configuration -------------------------------- Key: JBAS-8140 URL: https://jira.jboss.org/browse/JBAS-8140 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Domain Management Reporter: Brian Stansberry Fix For: Unscheduled This JIRA is based on feedback we received after the Andiamo BOF at JBoss World 2010: >> Would like to have a configuration with JBossTM JTS implementation >> already installed and optimized for servers that need distributed >> transactions. Proper transaction management is an advanced topic for >> JBoss admins and having Redhat's expertise already configured on a >> server is very reassuring. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

5
8
0 / 0

[JBoss JIRA] Created: (JBREM-552) cannot init cause of ClassCastException

by John Mazzitelli (JIRA)

cannot init cause of ClassCastException --------------------------------------- Key: JBREM-552 URL: http://jira.jboss.com/jira/browse/JBREM-552 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.Beta2 (Boon) Reporter: John Mazzitelli Assigned To: Tom Elrod Priority: Minor Fix For: 2.0.0.CR1 (Boon) I'm in a catch clause within InvokerRegistry and I'm getting a weird exception thrown: java.lang.IllegalStateException: Can't overwrite cause at java.lang.Throwable.initCause(Throwable.java:320) at org.jboss.remoting.InvokerRegistry.loadClientInvoker(InvokerRegistry.java:447) at org.jboss.remoting.InvokerRegistry.createClientInvoker(InvokerRegistry.java:324) at org.jboss.remoting.Client.connect(Client.java:385) at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.getRemotingClient(JBossRemotingRemoteCommunicator.java:470) at org.jboss.on.communications.command.client.JBossRemotingRemoteCommunicator.send(JBossRemotingRemoteCommunicator.java:430) at org.jboss.on.communications.command.client.AbstractCommandClient.invoke(AbstractCommandClient.java:167) at org.jboss.on.communications.command.client.ClientCommandSender.send(ClientCommandSender.java:820) at org.jboss.on.communications.command.client.ServerPollingThread.run(ServerPollingThread.java:102) Look at line 447 and you'll see it is trying to init the cause of a ClassNotFoundException. Running in a debugger, the newly constructed exception created on 446 has a null cause. Looking then at Throwable.initCause and you'll see a null cause causes this IllegalStateException to be thrown. The cause needs to be "this", not null (I don't know why, seems like it should also look for null, but whatever - that's the way the JDK is written). The fix is simple - use the constructor that takes a throwable as its second parameter. Not sure why initCause it being used, as opposed to this constructor. e.g.: new ClassNotFoundException("Can not invoke loadClientInvokerClass method on " + transportFactoryClass, e); (notice the ", e" parameter). There are three other instances where initCause is called on ClassNotFoundException that also need to be fixed. See the other catch clauses in here. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

5
5
0 / 0

[JBoss JIRA] Created: (JGRP-1250) Properties for each message

by Bela Ban (JIRA)

Properties for each message --------------------------- Key: JGRP-1250 URL: https://jira.jboss.org/browse/JGRP-1250 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12 JGroups already has the ability to bypass certain protocols, e.g. NO_FC set in a message bypasses any flow control layer. It would be nice to do this for other protocols, too, e.g. SEQUENCER, but this needs to be done in a generic fashion. What should be done is to use *properties*, e.g. +reliable-mcast, -frag, +flowcontrol, -bundling etc. Based on these flags, each protocol decides whether to handle (or not) a message. The properties should not take up *any* space in a message if not set. This can probably be generalized, ie. by annotating a protocol with the props it provides, e.g. @Reliable @ReliableUnicast UNICAST, and by having code which matches the flags in a message and decides whether or not to process the message. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

5
11
0 / 0

[JBoss JIRA] Created: (SECURITY-176) Implement JBossRequestContext.asElement(Document)

by Anil Saldhana (JIRA)

Implement JBossRequestContext.asElement(Document) ------------------------------------------------- Key: SECURITY-176 URL: http://jira.jboss.com/jira/browse/SECURITY-176 Project: JBoss Security and Identity Management Issue Type: Task Security Level: Public (Everyone can see) Components: JBossXACML Affects Versions: 2.0.2-BETA6 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2.GA If provided a Document, then create an element with the request details. Pretty cumbersome process. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

4
4
0 / 0

[JBoss JIRA] Created: (SECURITY-177) Implement JBossResponseContext.asElement(Document)

by Anil Saldhana (JIRA)

Implement JBossResponseContext.asElement(Document) -------------------------------------------------- Key: SECURITY-177 URL: http://jira.jboss.com/jira/browse/SECURITY-177 Project: JBoss Security and Identity Management Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JBossXACML Affects Versions: 2.0.2-BETA6 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2.GA -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

3
3
0 / 0

[JBoss JIRA] Created: (JBWEB-186) Using the native connector causes the JVM to crash when shutting down on Windows

by Mike Millson (JIRA)

Using the native connector causes the JVM to crash when shutting down on Windows -------------------------------------------------------------------------------- Key: JBWEB-186 URL: https://jira.jboss.org/browse/JBWEB-186 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Affects Versions: JBossWeb-3.0.0.Beta7 Reporter: Mike Millson Assignee: Remy Maucherat Boss server is crashing with an "EXCEPTION_ACCESS_VIOLATION" once shutdown has started. Setting a breakpoint in AccessLogValve.invoke() then doing shutdown, then releasing the break point crashes the JVM. The fatal error log shows the following: # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0d74c90e, pid=3204, tid=5944 # # JRE version: 6.0_20-b02 # Java VM: Java HotSpot(TM) Server VM (16.3-b01 mixed mode windows-x86 ) # Problematic frame: # C [libapr-1.dll+0xc90e] # ... Current thread (0x05973400): JavaThread "http-127.0.0.1-8080-2" daemon [_thread_in_native, id=5944, stack(0x0efe0000,0x0f030000)] ... Stack: [0x0efe0000,0x0f030000], sp=0x0f02f628, free space=13d0f02f15ck Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libapr-1.dll+0xc90e] C [libtcnative-1.dll+0x1150] j org.apache.tomcat.jni.Address.get(IJ)J+0 j org.apache.coyote.http11.Http11AprProcessor.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V+196 j org.apache.coyote.Request.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V+56 j org.apache.catalina.connector.Request.getRemoteAddr()Ljava/lang/String;+18 j org.apache.catalina.connector.Request.getRemoteHost()Ljava/lang/String;+19 j org.apache.catalina.valves.AccessLogValve$HostElement.addElement(Ljava/lang/StringBuffer;Ljava/util/Date;Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;J)V+2 j org.apache.catalina.valves.AccessLogValve.invoke(Lorg/apache/catalina/connector/Request;Lorg/apache/catalina/connector/Response;)V+115 ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

3
10
0 / 0

[JBoss JIRA] Created: (JGRP-1194) Revisit implementation of TUNNEL and shared transport

by Vladimir Blagojevic (JIRA)

Revisit implementation of TUNNEL and shared transport ----------------------------------------------------- Key: JGRP-1194 URL: https://jira.jboss.org/jira/browse/JGRP-1194 Project: JGroups Issue Type: Task Affects Versions: 2.9, 2.8 Reporter: Vladimir Blagojevic Assignee: Vladimir Blagojevic Fix For: 3.0 TUNNEL and shared transport are not supported at the moment (2.10.Alpha5). The main complexity behind TUNNEL and shared transport is that we have to change StubReceiver model. StubReceiver reads messages of the socket on the TUNNEL side. With shared transport turned on StubReceiver would have to be changed because we are receiving byte arrays for all channels sharing transport. We need some special StubReceiver multiplexer so to speak which will read messages and then pass off the byte arrays to other Receivers which will in turn pass them as messages to appropriate channel above transport. Each byte array passed around have to be pre appended with some identifier....and so on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

4
3
0 / 0

[JBoss JIRA] Created: (JGRP-809) Copyless stack

by Bela Ban (JIRA)

Copyless stack -------------- Key: JGRP-809 URL: https://jira.jboss.org/jira/browse/JGRP-809 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 Currently (as of 2.7), the transport reads the contents of a received packet into a buffer, then passes a *copy* of the buffer to a thread from the OOB or incoming thread pools. To prevent this copy, we can - have the receiver read only the version and OOB flag (to see which thread pool to dispatch the packet to) - pass a ref to the socket to a thread from the incoming of OOB pool, have that thread read the packet and return - each thread in the pool has its own buffer into which the buffer is read from the socket Possibly use NIO: we can install a selector and get woken up whenever data to be read is present. At that point, we can pass the ref to the socket to the handler thread and return immediately. NIO with channels for multicast sockets is available only in JDK 7 (or 8?), so this is a bit off... However, we can already implement this with reading the version and flags bytes and then passing the socket to the handler -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

2
6
0 / 0

[JBoss JIRA] Created: (JGRP-815) Scatter/Gather to avoid copying

by Bela Ban (JIRA)

Scatter/Gather to avoid copying ------------------------------- Key: JGRP-815 URL: https://jira.jboss.org/jira/browse/JGRP-815 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.8 When we invoke Channel.send(), we pass a bufffer to JGroups. At the transport level, JGroups marshals the sender and destination address, plus all headers and the buffer into a new byte[] buffer, which is then passed to the socket (DatagramSocket, MulticastSocket, Socket). We cannot do gathering writes on a DatagramSocket because DatagramSocket doesn't expose this functionality, contrary to a DatagramChannel. We could avoid having to copy the user's buffer by using gathering writes: effectively passing to the socket NIO ByteBuffers containing: 1: Src and dest address plus flags, plus possibly size 2: The marshalled headers 3: The buffer passed to JGroups by the user We can obtain a gathering-write channel as follows: ByteBuffer[] buffers; // contains the 3 byte buffers above DatagramSocket sock; DatagramChannel ch=sock.getChannel(); ch.write(buffers, 0, length); // length is the number of bytes of the total marshalled message This is supported by a GatheringByteChannel. I don't think there's currently a need to do scattered reads, but this needs to get investigated more. Also investigate whether MulticastSockets support gathering writes (whether they expose the correct DatagramChannel). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 8 months

2
8
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 2010