December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCLUSTER-155) EJBTransactionRolledBackException in EJB3 application after bringing down the first member of the cluster.

by Phillip Thurmond (JIRA)

EJBTransactionRolledBackException in EJB3 application after bringing down the first member of the cluster. ---------------------------------------------------------------------------------------------------------- Key: JBCLUSTER-155 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-155 Project: JBoss Clustering Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: Q4Y6 Environment: Clustering QA Lab. Linux x86_64 on Sun jdk 1.5 Reporter: Phillip Thurmond Assigned To: Brian Stansberry Using the ejb3 application at https://svn.jboss.org/repos/qa/ejb3demo . JBoss 4.0.5.GA with ejb3 from https://svn.jboss.org/repos/jbossas/tags/JBoss_4_0_5_GA_EJBTHREE-798/ . I create two identical server configurations for the ejb3demo application from the all config. I enable query caching in persistence.xml. To reproduce: 1. start up first instance, place order. 2. start up second instance, watch for cluster notification and join. Place order on second and first instances. 3. bring down first instance, watch for cluster removal messages on second host. Place order and receive an EJBTransactionRolledBackException in the browser. No stack traces or error messages are logged on the console. -- 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

19 years, 4 months

4
6
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-136) Set up project in SVN

by Brian Stansberry (JIRA)

Set up project in SVN --------------------- Key: JBCLUSTER-136 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-136 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q3Y6 Determine where in the repository the project should reside, layout project structure, etc. -- 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

19 years, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1020) Replace direct uses of Log4J by JBoss logging.

by Chris Laprun (JIRA)

Replace direct uses of Log4J by JBoss logging. ---------------------------------------------- Key: JBPORTAL-1020 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1020 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.4 Final, 2.2 Branch Reporter: Chris Laprun Priority: Minor Fix For: 2.6.Alpha1 -- 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

19 years, 4 months

3
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-848) Implement putFromExternalRead()

by Manik Surtani (JIRA)

Implement putFromExternalRead() ------------------------------- Key: JBCACHE-848 URL: http://jira.jboss.com/jira/browse/JBCACHE-848 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.GA This is to supercede putFailFast() in JBC 1.x as well as the Option.FAIL_SILENTLY option, for Hibernate to use when doing a DB read and putting the contents into the cache. See forum link for details of this. -- 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

19 years, 4 months

2
6
0 / 0

[JBoss JIRA] Created: (JGRP-372) TCP with SSL

by Bela Ban (JIRA)

TCP with SSL ------------ Key: JGRP-372 URL: http://jira.jboss.com/jira/browse/JGRP-372 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4.1 Attachments: tcp_ssl.jar >From Hal Hildebrand: Here's the straight TCP version, as I am still working on the handshake implementation for the TCP_NIO_SSL protocol. This protocol stack element provides security and authentication (using client side authentication) for a JGroups TCP stack. Like the NIO version, this required four minor modifications in the ConnectionTable class. These modifications allow one to subclass to create a connection table which uses SSL for the connections. Finally, there is a new protocol stack element, TCP_SSL, which one can add to a stack to make use of it. As with my previous request, it would be nice to have the changes to ConnectionTable make it into the mainline, as I currently have to overwrite the original class to easily implement this. The mods are simple and innocuous (marked with "HSH"). Right now, the TCP_SSL needs to be configured with an SSLContext. I didn't bother with integrating with the normal JGroups mechanism using properties from the configuration because I consider it inherently insecure to ensconce my passwords in configuration files, but the changes to enable this are straight forward. Currently, to configure the factory for the protocol layer, do something like the following before connecting your channel: // Construct your Jchannel JChannel jchannel = ... // Access your protocol stack ProtocolStack protocolStack = jchannel.getProtocolStack(); // Retrieve the TCP_SSL protocol layer TCP_SSL protocol = (TCP_SSL) protocolStack.findProtocol("TCP_SSL"); // Create your SSLContext SSLContext sslContext = .... // Set up the protocol protocol.setSslContext(sslContext); // Connect your channel jchannel.connnect("my-group"); Cheers. -- 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

19 years, 4 months

3
9
0 / 0

[JBoss JIRA] Created: (JGRP-369) ViewAccepted is not received as expected.

by ￘yvind Eikeland (JIRA)

ViewAccepted is not received as expected. ----------------------------------------- Key: JGRP-369 URL: http://jira.jboss.com/jira/browse/JGRP-369 Project: JGroups Issue Type: Bug Affects Versions: 2.4 Environment: Windows XP. java version "1.6.0-rc" Java(TM) SE Runtime Environment (build 1.6.0-rc-b104) Java HotSpot(TM) Client VM (build 1.6.0-rc-b104, mixed mode, sharing) Version: 2.4.0 CVS: $Id: Version.java,v 1.42 2006/10/31 12:45:32 belaban Exp $ History: (see doc/history.txt for details) Reporter: ￘yvind Eikeland Assigned To: Bela Ban Hi, We're evaluating JGroups and find its functionality very useful so far. We have built an application using State transfer using JChannel.getState() and message sending using PushPullAdapter.send(). We depend on viewAccepted messages to be securely sent and received. I've discovered behaviour that seems like a bug - please advise if we can configure the protocol stack differently to avoid this issue. I've reproduced the behaviour using org.jgroups.demos.Draw application. It happens almost every time. You should be able to do the same. 1. start 3 clients in different dos shells. (java -classpath %CP% org.jgroups.demos.Draw) 2. stop the coordinator client using the "Leave" button in the GUI. Do not kill the VM. A viewAccepted message is sent to the other two apps. A new coordinator is elected by Jgroups. 3. start the first client again. A viewAccepted message is received by all clients 4. kill the coordinator client (kill the VM). I guess this is the same behaviour as if the network was partitioned. Now, only suspect messages are coming through - indefinetely (Draw does not print those messages). A view accepted is not received. If you skip step 2 and 3 above, and only do 1 and 4, a viewAccepted message is sent and it all works. I edited ExtendedReceiverAdapter to print this message for convenience: public void suspect(Address suspected_mbr) { System.out.println("Received suspect: " + suspected_mbr.toString()); } Question: - is this a bug, or is it something wrong with the protocol setup, that we can change to make this work? C:\data\mars\3rdparty\JGroups-2.4.0.src>java -classpath %CP% org.jgroups.demos.D raw log4j:WARN No appenders could be found for logger (org.jgroups.JChannel). log4j:WARN Please initialize the log4j system properly. ------------------------------------------------------- GMS: address is 192.168.2.128:2143 ------------------------------------------------------- ** View=[192.168.2.128:2136|4] [192.168.2.128:2136, 192.168.2.128:2139, 192.168. 2.128:2143] Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 Received suspect: 192.168.2.128:2136 -- 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

19 years, 4 months

4
10
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1046) documentation for Ldap/Portal integration

by Boleslaw Dawidowicz (JIRA)

documentation for Ldap/Portal integration ----------------------------------------- Key: JBPORTAL-1046 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1046 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal Documentation Affects Versions: 2.6.Alpha1 Reporter: Boleslaw Dawidowicz Assigned To: Boleslaw Dawidowicz Fix For: 2.6.Alpha1 Create documentation of configuring Portal with LDAP. It needs to cover new implementation of identity modules in 2.6 -- 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

19 years, 4 months

3
6
0 / 0

[JBoss JIRA] Created: (SECURITY-15) Docbook for Security Project

by Anil Saldhana (JIRA)

Docbook for Security Project ---------------------------- Key: SECURITY-15 URL: http://jira.jboss.com/jira/browse/SECURITY-15 Project: JBoss Security Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Documentation Affects Versions: 2.0 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0 Create a Doc Book project for security -- 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

19 years, 4 months

2
1
0 / 0

[JBoss JIRA] Created: (JBBUILD-326) JBossRetro missing getDeclaredAnnotations; getAnnotations implementation is deficient

by David Lloyd (JIRA)

JBossRetro missing getDeclaredAnnotations; getAnnotations implementation is deficient ------------------------------------------------------------------------------------- Key: JBBUILD-326 URL: http://jira.jboss.com/jira/browse/JBBUILD-326 Project: JBoss Build System Issue Type: Bug Components: JBossRetro Affects Versions: JBossRetro-1.0.4.GA Reporter: David Lloyd Priority: Minor Fix For: JBossRetro-1.0.5.GA I put in a fix to JBossRetro to add support for getDeclaredAnnotations on Method, Field, Constructor, and AccessibleObject. In doing this I realized that getAnnotations seems to be doing what getDeclaredAnnotations is supposed to be doing; according to the JDK javadocs, getAnnotations is supposed to return inherited annotations as well as declared annotations, whereas getDeclaredAnnotations only returns annotations on the specific object. I committed a change to implement getDeclaredAnnotations which essentially duplicates the current getAnnotations behavior, but someone may want to go in and enhance getAnnotations. I'm attaching the patch that I committed in case I'm wrong and someone wants to revert it. -- 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

19 years, 4 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-3781) Stateful SB Instance Interceptor should not push SubjectContext if RunAsIdentity present

by Anil Saldhana (JIRA)

Stateful SB Instance Interceptor should not push SubjectContext if RunAsIdentity present ---------------------------------------------------------------------------------------- Key: JBAS-3781 URL: http://jira.jboss.com/jira/browse/JBAS-3781 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2 Affects Versions: JBossAS-4.0.5.GA, JBossAS-3.2.8.SP1, JBossAS-5.0.0.Beta Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.6.CR1 The following Subject Context push (with null Subject) to establish client security context should not be performed if the user has configured a RunAsIdentity in the caller bean. /* The security context must be established before the cache lookup because the activation of a session should have the caller's security context as ejbActivate is allowed to call other secured resources. Since the pm makes the ejbActivate call, we need to set the caller's security context. The only reason this shows up for stateful session is that we moved the SecurityInterceptor to after the instance interceptor to allow security exceptions to result in invalidation of the session. This may be too literal an interpretation of the ejb spec requirement that runtime exceptions should invalidate the session. */ SecurityActions.pushSubjectContext(mi.getPrincipal(), mi.getCredential(), null); The resolution is: if(SecurityActions.peekRunAsIdentity() == null) SecurityActions.pushSubjectContext(mi.getPrincipal(), mi.getCredential(), null); -- 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

19 years, 4 months

4
4
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 December 2006