December 2010 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-1258) NAKACK: remove max_xmit_buf_size

by Bela Ban (JIRA)

NAKACK: remove max_xmit_buf_size -------------------------------- Key: JGRP-1258 URL: https://jira.jboss.org/browse/JGRP-1258 Project: JGroups Issue Type: Task Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12 This property discards the oldest N message (even undelivered one), to keep the max number of messages buffered for retransmission to max_xmit_buf_size. However, this leads to issues. E.g. when P sent a message M, then discards it because max_xmit_buf_size has been exceeded, and then a member Q asks P for retransmission of M, P won't be able to furnish M ! We don't have a concept of being able to tell Q that it will never receive M and should therefore skip it. This would require quite some code changes, so we don't do it here (maybe later). -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-1255) AUTH: merging bypasses authorization process

by Bela Ban (JIRA)

AUTH: merging bypasses authorization process -------------------------------------------- Key: JGRP-1255 URL: https://jira.jboss.org/browse/JGRP-1255 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 2.12 AUTH checks admission into the group at JOIN time, but *not* at MERGE time ! To reproduce: - Copy auth.xml from JGroups/conf - Copy auth.xml to auth1.xml - Change the password in auth1.xml from "chris" to "chrissie" - Add <DISCARD use_gui="true"/> just above the transport to *both* auth.xml and auth1.xml - Start the instance A: java org.jgroups.demos.Draw -props ./auth.xml -name A - In the discard dialog box, click on "start discarding" - Start instance B: java org.jgroups.demos.Draw -props ./auth1.xml -name B - A and B will form 2 singleton clusters {A} and {B} - In instance A: click on "stop discarding" in the discard dialog box - A and B will merge into a cluster {A,B} SOLUTION: AUTH also needs to hook into the merge process and prevent a merge if authorization fails -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-1257) ENCRYPT protocol UnrecoverableKeyException: Given final block not properly padded

by Andres Garcia Garcia (JIRA)

ENCRYPT protocol UnrecoverableKeyException: Given final block not properly padded --------------------------------------------------------------------------------- Key: JGRP-1257 URL: https://jira.jboss.org/browse/JGRP-1257 Project: JGroups Issue Type: Bug Affects Versions: 2.11, 2.8, 2.7 Environment: Windows XP SP3, Java 1.6 Reporter: Andres Garcia Garcia Assignee: Bela Ban Recently I updated my jgroups version from 2.4.x to 2.11. Suddenly my applications thrown this exception. org.jgroups.ChannelException: unable to setup the protocol stack: Given final block not properly padded at org.jgroups.JChannel.init(JChannel.java:1574) at org.jgroups.JChannel.<init>(JChannel.java:257) at org.jgroups.JChannel.<init>(JChannel.java:240) at org.jgroups.demos.Draw.<init>(Draw.java:52) at org.jgroups.demos.Draw.main(Draw.java:141) Caused by: java.security.UnrecoverableKeyException: Given final block not properly padded at com.sun.crypto.provider.SunJCE_z.a(DashoA13*..) at com.sun.crypto.provider.JceKeyStore.engineGetKey(DashoA13*..) at java.security.KeyStore.getKey(Unknown Source) at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:269) at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:231) at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:641) at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:468) at org.jgroups.JChannel.init(JChannel.java:1570) ... 4 more The ENCRYPT protocol config is <ENCRYPT sym_init="448" sym_algorithm="Blowfish" encrypt_entire_message="true" key_store_name="cloudencrypt.keystore" store_password="password" alias="test"/> I tested the same code with different versions. 2.6.15 GA is the last working version, and every version I tested from 2.7 GA to 2.11 GA throw the same exception. I made a little use case with it. Maybe I am missing something? -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
8
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2212) Regression: @ApplicationException is not properly processed for jars in lib directories

by Carlo de Wolf (JIRA)

Regression: @ApplicationException is not properly processed for jars in lib directories --------------------------------------------------------------------------------------- Key: EJBTHREE-2212 URL: https://jira.jboss.org/browse/EJBTHREE-2212 Project: EJB 3.0 Issue Type: Bug Reporter: Carlo de Wolf Assignee: Carlo de Wolf Priority: Critical -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1728) Create a JTA profile for use in unit tests

by Carlo de Wolf (JIRA)

Create a JTA profile for use in unit tests ------------------------------------------ Key: EJBTHREE-1728 URL: https://jira.jboss.org/jira/browse/EJBTHREE-1728 Project: EJB 3.0 Issue Type: Feature Request Reporter: Carlo de Wolf Assignee: Carlo de Wolf -- 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

13 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1232) A failing commit must not throw a RuntimeException

by Carlo de Wolf (JIRA)

A failing commit must not throw a RuntimeException -------------------------------------------------- Key: EJBTHREE-1232 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1232 Project: EJB 3.0 Issue Type: Bug Reporter: Carlo de Wolf Assigned To: Carlo de Wolf Fix For: AS 5.0.0.CR1 java.lang.RuntimeException: javax.transaction.RollbackException: [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Can't commit because the transaction is in aborted state at org.jboss.aspects.tx.TxPolicy.handleEndTransactionException(TxPolicy.java:198) -- 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

13 years, 5 months

2
11
0 / 0

[JBoss JIRA] Created: (JBAS-5102) Crossreferencing EJBs using comp-names does not work

by Christian Nolte (JIRA)

Crossreferencing EJBs using comp-names does not work ---------------------------------------------------- Key: JBAS-5102 URL: http://jira.jboss.com/jira/browse/JBAS-5102 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB3 Affects Versions: JBossAS-4.2.2.GA Reporter: Christian Nolte Assigned To: Carlo de Wolf I have two stateless session beans which are referencing each other like that: @Stateless public class SessionBeanA implements SessionBeanALocal { @EJB private SessionBeanB sessionB; } and @Stateless public class SessionBeanB implement SessionBeanBLocal { @EJB private SessionBeanA sessionA; } When deploying the application on JBoss AS I get --- MBeans waiting for other MBeans --- ObjectName: jboss.j2ee:jar=test.jar,name=SessionBeanA,service=EJB3 State: NOTYETINSTALLED I Depend On: jboss.j2ee:jar=test.jar,name=SessionBeanB,service=EJB3 persistence.units:jar=test.jar,unitName=test.jar Depends On Me: jboss.j2ee:jar=test.jar,name=SessionBeanB,service=EJB3 ObjectName: jboss.j2ee:jar=test.jar,name=SessionBeanB,service=EJB3 State: NOTYETINSTALLED I Depend On: jboss.j2ee:jar=test.jar,name=SessionBeanA,service=EJB3 Depends On Me: jboss.j2ee:jar=test.jar,name=SessionBeanA,service=EJB3 and the deployment fails. -- 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

13 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (JBWEB-190) TomcatResolver in RewriteValve can't resolve environment variable previously stored by a RewriteRule directive

by Wenwei Liao (JIRA)

TomcatResolver in RewriteValve can't resolve environment variable previously stored by a RewriteRule directive -------------------------------------------------------------------------------------------------------------- Key: JBWEB-190 URL: https://jira.jboss.org/browse/JBWEB-190 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Rewrite Valve Reporter: Wenwei Liao Assignee: Remy Maucherat In the following test case, http://test.foo.net/news/123 will be rewrote into /null.do instead of /test.do RewriteCond %{HTTP_HOST} ^(.*).foo.net$ [NC] RewriteRule .* $0 [E=subdomain:%1] # news RewriteRule /news/(\d+) /%{ENV:subdomain}.do [L] It seems that subdomain=test has been stored into request.attributes but TomcatResolver doesn't retrive subdomain from request.attributes but via System.getProperty -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

2
4
0 / 0

[JBoss JIRA] Commented: (JBAS-8290) Implement solid SessionObjectReference

by Pete Muir (JIRA)

[ https://jira.jboss.org/browse/JBAS-8290?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on JBAS-8290: --------------------------------- The CDI TCK does not currently test this, however it is part of the web profile support for CDI, so should be in AS 6. > Implement solid SessionObjectReference > -------------------------------------- > > Key: JBAS-8290 > URL: https://jira.jboss.org/browse/JBAS-8290 > Project: JBoss Application Server > Issue Type: Bug > Components: Weld/CDI > Reporter: Pete Muir > Assignee: Marius Bogoevici > Priority: Blocker > Fix For: 6.0.0.Final > > > JBossSessionObjectReference is a bit hacky right now: > 1) Needs a proper implementation of isRemoved which interrogates the EJB container to determine the state of the reference > 2) Needs a Remove implementation that can cope with no-interface-view beans > 3) Needs to lookup the actual reference for getBusinessObject() not just cast the local proxy. Note that we may request remote EJBs through this mechanism! -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

[JBoss JIRA] Commented: (JBAS-8286) Wrong classloader used in InterceptorMethodHandler.readObject in JBoss AS

by Pete Muir (JIRA)

[ https://jira.jboss.org/browse/JBAS-8286?page=com.atlassian.jira.plugin.sy... ] Pete Muir commented on JBAS-8286: --------------------------------- Marius or someone, can you provide a hint about how to test serialization in the AS? > Wrong classloader used in InterceptorMethodHandler.readObject in JBoss AS > ------------------------------------------------------------------------- > > Key: JBAS-8286 > URL: https://jira.jboss.org/browse/JBAS-8286 > Project: JBoss Application Server > Issue Type: Bug > Affects Versions: TBD-6.x > Reporter: Pete Muir > Assignee: Marius Bogoevici > Fix For: 6.0.0.Final > > > See org.jboss.weld.test.unit.interceptor.passivation.PassivationActivationTest.testPassivationAndActivation() > It looks to me like the classloader of jboss-interceptor (the classloader for the deployer) is used to deserialize the proxy, whilst the WeldImpl exists on the application classloader -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2010