November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-623) First event in both Channel and MuxChannel should always be BLOCK and the last event should be UNBLOCK

by Vladimir Blagojevic (JIRA)

First event in both Channel and MuxChannel should always be BLOCK and the last event should be UNBLOCK ------------------------------------------------------------------------------------------------------ Key: JGRP-623 URL: http://jira.jboss.com/jira/browse/JGRP-623 Project: JGroups Issue Type: Bug Affects Versions: 2.6 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Priority: Minor Fix For: 2.6.1, 2.7 We ensure that block|unblock|view|get/setstate events are ordered did not ensure that a channel is returned into a starting state with respect to events. Therefore, Flush should always ensure that first event that channel receives should always be BLOCK and the last event should be UNBLOCK. Added this check in FlushTest. -- 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

17 years, 1 month

1
2
0 / 0

[JBoss JIRA] Created: (JGRP-622) Stop flush should be invoked by cluster members individually when flush coordinator leaves

by Vladimir Blagojevic (JIRA)

Stop flush should be invoked by cluster members individually when flush coordinator leaves ------------------------------------------------------------------------------------------ Key: JGRP-622 URL: http://jira.jboss.com/jira/browse/JGRP-622 Project: JGroups Issue Type: Bug Affects Versions: 2.6 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Currently when member A who is a coordinator leaves we execute flush coordinator transfer. That is member A starts flush for view V but member B completes it with stop flush. Member B, neighbor of A, receives a view V where coordinator is excluded, it takes over completion of flush. However, when B sends stop flush, then stop flush might arrive at member C *before* view V sent by A. Thus events get reordered. If each remaining member in V detects (through view) that member A left then each one of the members can complete flush individually by "pretending" that it received stop flush from A. This bug is likely to occur only with bundling disabled. -- 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

17 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-630) Setting option on MuxChannel (with Channel.setOpt(Channel.LOCAL, Boolean.FALSE) ) results in all MuxChannel not receiving any messages

by Vladimir Blagojevic (JIRA)

Setting option on MuxChannel (with Channel.setOpt(Channel.LOCAL,Boolean.FALSE) ) results in all MuxChannel not receiving any messages ------------------------------------------------------------------------------------------------------------------------------------- Key: JGRP-630 URL: http://jira.jboss.com/jira/browse/JGRP-630 Project: JGroups Issue Type: Bug Affects Versions: 2.6 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic Fix For: 2.6.1, 2.7 If an application creates a multiplexed channel and then sets an option on that channel: Channel.setOpt(Channel.LOCAL,Boolean.FALSE) then all messages destined to all MuxChannels on top of the same regular channel will be dropped. -- 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

17 years, 1 month

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-635) ConcurrentModificationException in FLUSH

by Robert Newson (JIRA)

ConcurrentModificationException in FLUSH ---------------------------------------- Key: JGRP-635 URL: http://jira.jboss.com/jira/browse/JGRP-635 Project: JGroups Issue Type: Bug Affects Versions: 2.6 Reporter: Robert Newson Assigned To: Bela Ban ERROR - failed sending message to null (160 bytes) java.util.ConcurrentModificationException at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372) at java.util.AbstractList$Itr.next(AbstractList.java:343) at org.jgroups.protocols.pbcast.FLUSH$FlushHeader.writeTo(FLUSH.java:890) at org.jgroups.Message.writeHeader(Message.java:799) at org.jgroups.Message.writeTo(Message.java:685) at org.jgroups.protocols.TP.writeMessage(TP.java:1234) at org.jgroups.protocols.TP.send(TP.java:1199) at org.jgroups.protocols.TP.down(TP.java:963) at org.jgroups.protocols.Discovery.down(Discovery.java:351) at org.jgroups.protocols.MERGE2.down(MERGE2.java:176) at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:364) at org.jgroups.protocols.FD.down(FD.java:357) at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:95) at org.jgroups.protocols.BARRIER.down(BARRIER.java:97) at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:766) at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:568) at org.jgroups.protocols.UNICAST.down(UNICAST.java:437) at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:317) at org.jgroups.protocols.VIEW_SYNC.down(VIEW_SYNC.java:173) at org.jgroups.protocols.pbcast.GMS.down(GMS.java:838) at org.jgroups.protocols.FRAG2.down(FRAG2.java:175) at org.jgroups.protocols.pbcast.STATE_TRANSFER.down(STATE_TRANSFER.java:200) at org.jgroups.protocols.pbcast.FLUSH.onFlushCompleted(FLUSH.java:733) at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:350) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:144) at org.jgroups.protocols.FRAG2.up(FRAG2.java:205) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:767) at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:161) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234) at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:579) at org.jgroups.protocols.UNICAST.up(UNICAST.java:250) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:714) at org.jgroups.protocols.BARRIER.up(BARRIER.java:122) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167) at org.jgroups.protocols.FD.up(FD.java:322) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:300) at org.jgroups.protocols.MERGE2.up(MERGE2.java:145) at org.jgroups.protocols.Discovery.up(Discovery.java:246) at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1510) at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1459) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:619) : -- 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

17 years, 1 month

3
4
0 / 0

[JBoss JIRA] Updated: (JBAOP-253) Before release, submit the jar to the Messaging team for testing

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-253?page=all ] Kabir Khan updated JBAOP-253: ----------------------------- Fix Version/s: 2.0.0.CR2 (was: 2.0.0.CR1) > Before release, submit the jar to the Messaging team for testing > ---------------------------------------------------------------- > > Key: JBAOP-253 > URL: http://jira.jboss.com/jira/browse/JBAOP-253 > Project: JBoss AOP > Issue Type: Task > Reporter: Ovidiu Feodorov > Assigned To: Kabir Khan > Priority: Minor > Fix For: 2.0.0.CR2 > > -- 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

17 years, 1 month

1
0
0 / 0

[JBoss JIRA] Updated: (JBAOP-209) Change any usage of java.rmi.MarshalledObject with JBoss Serialization's equivalent.

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-209?page=all ] Kabir Khan updated JBAOP-209: ----------------------------- Fix Version/s: 2.0.0.CR2 (was: 2.0.0.CR1) > Change any usage of java.rmi.MarshalledObject with JBoss Serialization's equivalent. > ------------------------------------------------------------------------------------ > > Key: JBAOP-209 > URL: http://jira.jboss.com/jira/browse/JBAOP-209 > Project: JBoss AOP > Issue Type: Feature Request > Affects Versions: 1.3.5 > Reporter: Bill Burke > Assigned To: Bill Burke > Priority: Minor > Fix For: 2.0.0.CR2 > > -- 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

17 years, 1 month

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3812) TomcatDeployment should use modified WebMetaData

by Thomas Diesler (JIRA)

TomcatDeployment should use modified WebMetaData ------------------------------------------------ Key: JBAS-3812 URL: http://jira.jboss.com/jira/browse/JBAS-3812 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Reporter: Thomas Diesler Fix For: JBossAS-5.0.0.Beta The Web Service Deployers modify the WebMetaData. This should then be used to deploy to Tomcat. Rewrite of the war should not be necessary. -- 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

17 years, 1 month

6
11
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1814) 'Page layout' in admin portal works only for users called "admin"

by Tobias Roth (JIRA)

'Page layout' in admin portal works only for users called "admin" ----------------------------------------------------------------- Key: JBPORTAL-1814 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1814 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Admin Reporter: Tobias Roth In 'page layout' of the admin tool, portlet instances are only listed for the original admin user (i.e. callded 'admin', in role 'admin'). For other admin users, this list stays empty. How to reproduce: 1) build JBoss_Portal_Branch_2_6, deploy the portal, identity and admin 2) log in as admin 3) create a new role called newadminrole 4) create a new user called newadmin, add him _only_ to the newadminrole (no other roles) 5) give access to the admin portal to newadmin 6) give access to the adminportlet instance to newadmin 7) log out, log in as newadmin 8) go to the 'page layout' page of the default page 9) verify that no portlet instances are listed Some notes: - if you log in as admin, the portlet instances are listed - if you install cms or google widgets, lists of files appear for those Unless I forgot to set some specific permissions, this suspiciously looks like a bug. See JBPORTAL-1646 and JBPORTAL-1740 for similar, but not identic bugs. -- 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

17 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4353) request.getRequestURL/request.getRequestURI return different results depending on running behind mod_jk or not.

by Jon Stevens (JIRA)

request.getRequestURL/request.getRequestURI return different results depending on running behind mod_jk or not. --------------------------------------------------------------------------------------------------------------- Key: JBAS-4353 URL: http://jira.jboss.com/jira/browse/JBAS-4353 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web (Tomcat) service Affects Versions: JBossAS-4.2.0.CR2 Reporter: Jon Stevens Assigned To: Remy Maucherat Priority: Blocker Running with the bundled Tomcat on port 8080, i get this: requestUrl: http://HOSTNAME:8080/data/xxx/members/4457/pictures/thumbs/Behind%20the%2... requestUri: /data/xxx/members/4457/pictures/thumbs/Behind%20the%20Scenes/peter.jpg Running tomcat behind mod_jk, I get this: requestUrl: http://HOSTNAME/data/xxx/members/4457/pictures/thumbs/Behind the Scenes/peter.jpg requestUri: /data/xxx/members/4457/pictures/thumbs/Behind the Scenes/peter.jpg This is a blocker because I depend on knowing if the string is urlencoded or not. -- 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

17 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBWEB-77) Servlet throws NPE the first time it is hit.

by Phillip Thurmond (JIRA)

Servlet throws NPE the first time it is hit. -------------------------------------------- Key: JBWEB-77 URL: http://jira.jboss.com/jira/browse/JBWEB-77 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Phillip Thurmond Assigned To: Mladen Turk Priority: Blocker The first time a servlet is hit, it throws a NPE. After the exception is thrown, the servlet works correctly. Here is the stack trace. Example war attached. java.lang.NullPointerException at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:471) at org.apache.catalina.connector.CoyoteOutputStream.print(CoyoteOutputStream.java:113) at test.TestServlet.doGet(TestServlet.java:67) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:216) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:624) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445) at java.lang.Thread.run(Thread.java:595) -- 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

17 years, 1 month

2
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2007