November 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4940) Deployment.types not propagated

by Thomas Diesler (JIRA)

Deployment.types not propagated ------------------------------- Key: JBAS-4940 URL: http://jira.jboss.com/jira/browse/JBAS-4940 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Thomas Diesler -- 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

18 years, 8 months

2
11
0 / 0

[JBoss JIRA] Created: (JGRP-608) FLUSH not safe in simultaneous flush situation

by Michael Newcomb (JIRA)

FLUSH not safe in simultaneous flush situation ---------------------------------------------- Key: JGRP-608 URL: http://jira.jboss.com/jira/browse/JGRP-608 Project: JGroups Issue Type: Feature Request Affects Versions: 2.6 Reporter: Michael Newcomb Assigned To: Bela Ban I'm running into a few problems when multiple members request a FLUSH at the same time. I am still in the process of analyzing the situation, but here are a few problems: private void handleStartFlush(Message msg, FlushHeader fh) { byte oldPhase = flushPhase.transitionToFirstPhase(); if(oldPhase == FlushPhase.START_PHASE){ sendBlockUpToChannel(); onStartFlush(msg.getSrc(), fh); }else if(oldPhase == FlushPhase.FIRST_PHASE){ Address flushRequester = msg.getSrc(); Address coordinator = null; synchronized(sharedLock){ if(flushCoordinator != null) coordinator = flushCoordinator; else coordinator = flushRequester; } After a successful transtion to the first phase, onStartFlush is called. Inside the method, the flushCoordinator is set. However a simultaneous handleStartFlush from another member would fail the transitionToFirstPhase() call, but it is possible that the flushCoordinator might not be set yet and the second handleStartFlush would end up setting the 'coordinator' to the flushRequestor. This could grant the second START_FLUSH a FLUSH_OK without rejecting the flush that succeeded in the transitionToFirstPhase(). IMHO the transitionToFirstPhase() should assign the flushCoordinator at that time to avoid the above situation, in fact, all of the protected parts of the onStartFlush() call should be made inside the protected section of transitionToFirstPhase(). The above should take care of the didn't-succeed-in-transitionToFirstPhase-but-became-flushCoordinator-anyways-because-flushCoordinator-wasn't-set-yet problem. Now, there is another problem in the way simultaneous START_FLUSHes are resolved. If the new flushRequestor is < the current flushCoordinator the new requestor will win the flush fight. This is a great strategy because all the members will get the same result here. If A, B, C are members and A < B < C and they all simultaneously request a flush, then the desired effect is for everyone to decide that A will win the flush fight. So the following code handles that situation... private void handleStartFlush(Message msg, FlushHeader fh) { ... }else if(oldPhase == FlushPhase.FIRST_PHASE){ ... if(flushRequester.compareTo(coordinator) < 0){ rejectFlush(fh.viewID, coordinator); ... synchronized(sharedLock){ flushCoordinator = flushRequester; } } If the new flushRequetor is < the old flushCoordinator than reject/abort the old flush. However, the new flushCoordinator is never acknowledged by a onStartFlush (which sends FLUSH_OK). If we moved all the protected parts of onStartFlush() to transitionToFirstPhase() then the flush members would never be set properly, so that situation needs to be resolved as well. I think this might be the problem I'm seeing because I wait indefinitely for my flush to succeed. I will be testing a patch this afternoon and hope to report back. -- 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

18 years, 8 months

3
17
0 / 0

[JBoss JIRA] Created: (JGRP-618) FLUSH coordinator transfer reorders block/unblock/view events in applications (TCP stack only)

by Vladimir Blagojevic (JIRA)

FLUSH coordinator transfer reorders block/unblock/view events in applications (TCP stack only) ---------------------------------------------------------------------------------------------- Key: JGRP-618 URL: http://jira.jboss.com/jira/browse/JGRP-618 Project: JGroups Issue Type: Bug Affects Versions: 2.6 Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic When flush coordinator A runs a flush for a view that excludes himself a flush coordinator transfer occurs. Member B that is first next neighbor of A according to view has to complete the flush by sending STOP_FLUSH to all. Simplification of FLUSH JGRP-598 removed complex stop flush phase. In new design as soon as member receives STOP_FLUSH it unblocks application by sending UNBLOCK. Now, during coordinator transfer described above we first have to send a view up to application and then invoke STOP_FLUSH. If we do it other way around STOP_FLUSH will loop back and cause delivery of UNBLOCK to application prior to new view - thus causing reordering of block/unblock/view events in applications. -- 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

18 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1317) Rule Execution Very Slow on Subsequent Session Using the Same Packages

by Ming Jin (JIRA)

Rule Execution Very Slow on Subsequent Session Using the Same Packages ---------------------------------------------------------------------- Key: JBRULES-1317 URL: http://jira.jboss.com/jira/browse/JBRULES-1317 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 4.0.3 Environment: Windows XP Reporter: Ming Jin Using the same packages, repeatedly creating a new ruleBase and stateless session, then executing rules. The timing of rule execution was good on first time, but 6+ times slower on subsequent calls, such as the following: Time of rule execution: 0.06 Time of rule execution: 3.956 Time of rule execution: 3.926 Time of rule execution: 3.995 Time of rule execution: 3.906 When under debugger, such as running in IntelliJ, the second execution call would pause (dead lock?). I have a test program to demonstrate this behavior. -- 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

18 years, 8 months

3
10
0 / 0

[JBoss JIRA] Created: (JBAS-4658) The jms destinations classes need to be updated with management annotations

by Scott M Stark (JIRA)

The jms destinations classes need to be updated with management annotations --------------------------------------------------------------------------- Key: JBAS-4658 URL: http://jira.jboss.com/jira/browse/JBAS-4658 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: JMS service, Management services Reporter: Scott M Stark Assigned To: Adrian Brock Fix For: JBossAS-5.0.0.Beta3 The org.jboss.jms.server.destination.QueueService/TopicService and org.jboss.jms.server.connectionfactory.ConnectionFactory need to be updated with management annotations for creating the ManagedObjects. -- 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

18 years, 8 months

3
8
0 / 0

[JBoss JIRA] Created: (JBCOMMON-29) Unable to read in jarfile if application installed to location with spaces in directory name

by klaasjan elzinga (JIRA)

Unable to read in jarfile if application installed to location with spaces in directory name -------------------------------------------------------------------------------------------- Key: JBCOMMON-29 URL: http://jira.jboss.com/jira/browse/JBCOMMON-29 Project: JBoss Common Issue Type: Bug Security Level: Public (Everyone can see) Components: core Affects Versions: 2.0.4.GA Environment: windows XP sun-jre, happens also in core-2.2.0.GA Reporter: klaasjan elzinga Assigned To: Dimitris Andreadis I get an exception if the application is installed to a directory containing a space. I I rename the directory to a name without a space, the application runs perfectly. Exception in thread "main" org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [loadtool/applicationContext.xml]: Invocation of init method failed; nested exception is java.lang.RuntimeException: error trying to scan <jar-file>: file:/C:/TIS%20FIIBLoadTool-3.0.2.SN APSHOT/TISFIIBLoadTool-3.0.2.SNAPSHOT-jar-with-dependencies.jar Caused by: java.lang.RuntimeException: error trying to scan <jar-file>: file:/C:/TIS%20FIIBLoadTool-3.0.2.SNAPSHOT/TISFIIBLoadTool-3.0.2.SNAPSHOT-jar-with-dependencies.jar at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:635) at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:350) at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:126) at org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:218) at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:251) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1201) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1171) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:425) at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251) at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:156) at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248) ... at loadtool.Main.main(Main.java:40) Caused by: java.lang.RuntimeException: java.io.FileNotFoundException: C:\TIS%20FIIBLoadTool-3.0.2.SNAPSHOT\TISFIIBLoadTool-3.0.2.SNAPSHOT-jar-with-dependencies.jar (The system cannot find th e path specified) at org.jboss.util.file.JarArchiveBrowser.<init>(JarArchiveBrowser.java:74) at org.jboss.util.file.FileProtocolArchiveBrowserFactory.create(FileProtocolArchiveBrowserFactory.java:48) at org.jboss.util.file.ArchiveBrowser.getBrowser(ArchiveBrowser.java:57) at org.hibernate.ejb.Ejb3Configuration.scanForClasses(Ejb3Configuration.java:626) ... 29 more Caused by: java.io.FileNotFoundException: C:\TIS%20FIIBLoadTool-3.0.2.SNAPSHOT\TISFIIBLoadTool-3.0.2.SNAPSHOT-jar-with-dependencies.jar (The system cannot find the path specified) at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.jar.JarFile.<init>(JarFile.java:133) at java.util.jar.JarFile.<init>(JarFile.java:97) at org.jboss.util.file.JarArchiveBrowser.<init>(JarArchiveBrowser.java:69) ... 32 more -- 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

18 years, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1773) Unable to destroy instance customization

by Ovidiu Nichifor (JIRA)

Unable to destroy instance customization ---------------------------------------- Key: JBPORTAL-1773 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1773 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core Affects Versions: 2.6.1 Final Environment: Fedora Core 7 JVM 1.5.0_12 JBoss [Zion] 4.0.5.GA (build: CVSTag=Branch_4_0 date=200610162339) (installed with jems-installer 1.2.0.GA with 'ejb3' profile) JBoss Potal 2.6.1.GA Reporter: Ovidiu Nichifor Assigned To: Julien Viet Create & place a window on a region of an ordinary page of your personal dashboard. Make sure it is visible on your dashboard. Destroy that window. Recreate the window with the same name, content type, instance, page parent, region and order as before. An error will appear in the console: 12:17:12,694 ERROR [AbstractInstance] Was not able to destroy local._4 for customization dashboard:/admin/sample/P, reason is : null 12:17:57,309 ERROR [AbstractInstance] Was not able to destroy local._3 for customization dashboard:/admin/sample/Preferences, reason is : null It seems that when a window is destroyed the entries from 'JBP_PORTLET_STATE' table are deleted but the customization entry from 'JBP_INSTANCE_PER_USER' is not; this entry references an invalid portlet ref in the previous table. Sample: `JBP_PORTLET_STATE` PK PORTLET_ID REGISTRATION_ID REGISTRATION_TIME TERMINATION_TIME PARENT_PK 1 /portal-news-samples.NewsPortlet NULL 2007-10-25 11:57:28 NULL NULL `JBP_INSTANCE_PER_USER` PK INSTANCE_PK SER_STATE USER_ID PORTLET_REF 1 16 [BLOB - NULL] dashboard:/admin/default/Preferences local._2 2 16 [BLOB - NULL] dashboard:/admin/sample/Preferences local._3 3 16 [BLOB - NULL] dashboard:/admin/sample/P local._4 Your newly created window does exist in the 'OBJECT_NODE' table but the portal will NOT render it anymore, especially if you restart the AS. Done some more debug and ended up with a NoSuchPortletException which is as expected since the persistent state (local._X) is no longer valid. Also, org.jboss.portal.core.impl.model.instance.AbstarctInstance#destroyCustomization does remove the customization state but does not delete the entry from 'JBP_INSTANCE_PER_USER'. -- 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

18 years, 8 months

3
5
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1787) Runtime clone before write of a Producer Offered Portlet using the remote storage state management strategy produces a local storage instead of a remote storage

by Julien Viet (JIRA)

Runtime clone before write of a Producer Offered Portlet using the remote storage state management strategy produces a local storage instead of a remote storage ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBPORTAL-1787 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1787 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Portlet Affects Versions: Portlet-1.0, Portlet-1.1, Portlet-1.0.1 Reporter: Julien Viet Assigned To: Julien Viet Fix For: Portlet-1.1, Portlet-1.0.1 -- 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

18 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (SECURITY-91) Pull out the authorization spi into a seperate authorization spi submodule

by Anil Saldhana (JIRA)

Pull out the authorization spi into a seperate authorization spi submodule -------------------------------------------------------------------------- Key: SECURITY-91 URL: http://jira.jboss.com/jira/browse/SECURITY-91 Project: JBoss Security and Identity Management Issue Type: Sub-task Security Level: Public (Everyone can see) Components: ACL, Security SPI Affects Versions: 2.0.1.GA Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2-BETA Need to separate out the Authorization SPI such that the ACL implementation can use it without the need for the entire security spi. -- 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

18 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (SECURITY-90) Create ACL Submodule

by Anil Saldhana (JIRA)

Create ACL Submodule -------------------- Key: SECURITY-90 URL: http://jira.jboss.com/jira/browse/SECURITY-90 Project: JBoss Security and Identity Management Issue Type: Sub-task Security Level: Public (Everyone can see) Components: ACL Affects Versions: 2.0.1.GA Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: 2.0.2-BETA Create a submodule under security-jboss-sx for the acl implementation. -- 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

18 years, 8 months

1
1
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 2007