July 2009 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (EJBTHREE-1721) Implement @Asynchronous

by Andrew Lee Rubinger (JIRA)

Implement @Asynchronous ------------------------ Key: EJBTHREE-1721 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1721 Project: EJB 3.0 Issue Type: Task Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Fix For: EJB 3.1 Container task for @Asynchronous handling as specified by EJB 3.1 -- 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, 6 months

4
5
0 / 0

[JBoss JIRA] Created: (JBRULES-443) Release drools binaries with debug information

by Juergen none (JIRA)

Release drools binaries with debug information ---------------------------------------------- Key: JBRULES-443 URL: http://jira.jboss.com/jira/browse/JBRULES-443 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: All Reporter: Juergen none Assigned To: Mark Proctor Priority: Trivial Would it be possible to supply a debug-build of the binaries in addition to the existing downloads (where at least the drools jar files are without debug-info)? -- 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, 7 months

3
4
0 / 0

[JBoss JIRA] Created: (JGRP-1002) Merge: make the coordinator remain the same if possible after a merge

by Bela Ban (JIRA)

Merge: make the coordinator remain the same if possible after a merge --------------------------------------------------------------------- Key: JGRP-1002 URL: https://jira.jboss.org/jira/browse/JGRP-1002 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 3.0 When we have {C, A, B} and split into {C,A} and {B}, then a merge will produce {A,B,C}. Therefore the coord is moved from C to A. For certain apps, e.g. JBoss singletons, this is not good, as we're moving the singleton services from a perfectly healthy node to a different node. GOAL: come up with a deterministic policy of picking a coord such that we minimize coord switching if the existing coord is still member of the cluster. This depends on or is related to the flexible coord pick policy JIRA issue -- 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, 7 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAS-6532) TCLFilter doesn't work in jboss 5 with war's in any documented way

by robert lazarski (JIRA)

TCLFilter doesn't work in jboss 5 with war's in any documented way ------------------------------------------------------------------ Key: JBAS-6532 URL: https://jira.jboss.org/jira/browse/JBAS-6532 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Logging Affects Versions: JBossAS-5.0.0.GA Environment: jdk 6, linux Reporter: robert lazarski Assignee: Scott M Stark Reading this doc: http://www.jboss.org/community/docs/DOC-12203 Indicates a *-exp.war syntax is needed for TCLFilter war use, but there are no files of that type on my system running jboss 5. I've tried all the possible combinations I can think of, posted the problem to the forum, and the result is always that the file sizes and contents of the log files generated are exactly the same for the different war's, ie, no separated content. Here's my current config: <appender name="penguinLog" class="org.apache.log4j.FileAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"></errorHandler> <param name="Append" value="false"/> <param name="File" value="${jboss.server.home.dir}/log/penguinLog.log"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d %-5p %c{1} %m%n"/> </layout> <filter class="org.jboss.logging.filter.TCLFilter"> <param name="AcceptOnMatch" value="true"/> <param name="DeployURL" value="penguin"/> </filter> </appender> <appender name="wtfLog" class="org.apache.log4j.FileAppender"> <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"></errorHandler> <param name="Append" value="false"/> <param name="File" value="${jboss.server.home.dir}/log/wtfLog.log"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d %-5p %c{1} %m%n"/> </layout> <filter class="org.jboss.logging.filter.TCLFilter"> <param name="AcceptOnMatch" value="true"/> <param name="DeployURL" value="wtf-exp.war"/> </filter> </appender> <root> <appender-ref ref="CONSOLE"/> <appender-ref ref="FILE"/> <appender-ref ref="penguinLog"/> <appender-ref ref="wtfLog"/> </root> -- 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, 7 months

7
13
0 / 0

[JBoss JIRA] Created: (JBAS-6657) managementView.load() fails to merge ServerInfo, ThreadPool, GlobalRequestProcessor, and Host ManagedObjects

by Ian Springer (JIRA)

managementView.load() fails to merge ServerInfo, ThreadPool, GlobalRequestProcessor, and Host ManagedObjects ------------------------------------------------------------------------------------------------------------ Key: JBAS-6657 URL: https://jira.jboss.org/jira/browse/JBAS-6657 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: ProfileService Reporter: Ian Springer Assignee: Scott M Stark Fix For: JBossAS-5.1.0.CR1 These are all MOs that are needed by the Embedded Console. Here's the log output: 10:47:18,464 DEBUG [ProfileServiceFactory] About to load profile via Management View... 10:47:23,964 WARN [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null 10:47:23,980 WARN [AbstractManagedObjectPopulator] Cannot create String name from non-Simple property: ManagedProperty{JNDIName,JNDIName,metaType=SimpleMetaType:java.lang.String}, value=null 10:47:57,870 WARN [ManagementViewImpl] Failed to merged the following runtime ManagedObjects: {jboss.system:type=ServerInfo/jboss.system:type=ServerInfo=ManagedObject{jboss.system:type=ServerInfo}, jboss.web:name=http-127.0.0.1-8080,type=ThreadPool/=ManagedObject{jboss.web:name=http-127.0.0.1-8080,type=ThreadPool}, jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor/=ManagedObject{jboss.web:name=http-127.0.0.1-8080,type=GlobalRequestProcessor}, jboss.web:host=127.0.0.1,type=Host/=ManagedObject{jboss.web:host=127.0.0.1,type=Host}} 10:48:00,917 DEBUG [ProfileServiceFactory] Loaded profile via Management View in 42453 milliseconds. -- 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, 7 months

4
3
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, 7 months

5
5
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, 7 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, 7 months

3
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 July 2009