May 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-759) Create a set of deadlock-detecting unit tests

by Manik Surtani (JIRA)

Create a set of deadlock-detecting unit tests --------------------------------------------- Key: JBCACHE-759 URL: http://jira.jboss.com/jira/browse/JBCACHE-759 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 1.4.0 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0 >From email thread: "Okay, found out that jconsole also supports it: MBeans --> java.lang --> Threading --> Operations --> findMonitorDeadlockedThreads(). Of course, if we could integrate this into our test suites to regularly check for deadlocks..." Article from JavaSpecialists: http://www.javaspecialists.co.za/archive/newsletter.do?issue=130&locale=e... -- 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, 4 months

3
5
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-152) Dependency names need to be validated earlier

by Scott M Stark (JIRA)

Dependency names need to be validated earlier --------------------------------------------- Key: JBMICROCONT-152 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-152 Project: JBoss MicroContainer Issue Type: Bug Components: Dependency Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossMC_2_0_0 Beta3 I'm seeing an error like the following testing profileservice attachments overrides: Caused by: java.lang.IllegalArgumentException: Null name at org.jboss.dependency.plugins.AbstractController.getContext(AbstractController.java:129) at org.jboss.kernel.plugins.dependency.AbstractKernelController.getContext(AbstractKernelController.java:101) at org.jboss.dependency.plugins.AbstractDependencyItem.resolve(AbstractDependencyItem.java:117) at org.jboss.dependency.plugins.AbstractDependencyInfo.resolveDependencies(AbstractDependencyInfo.java:128) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:595) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:531) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:489) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:289) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:192) at org.jboss.system.ServiceController.doInstall(ServiceController.java:638) at org.jboss.system.ServiceController.install(ServiceController.java:271) This error regarding the invalid dependency item name not showing up until there is an attempt to resolve it makes it impossible to debug the problem as there is no context in the dependency to understand why its 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

18 years, 4 months

3
11
0 / 0

[JBoss JIRA] Created: (JBOSGI-10) OSGi Listeners

by Adrian Brock (JIRA)

OSGi Listeners -------------- Key: JBOSGI-10 URL: http://jira.jboss.com/jira/browse/JBOSGI-10 Project: JBoss OSGi Issue Type: Task Security Level: Public (Everyone can see) Reporter: Adrian Brock Assigned To: Adrian Brock OSGi defines three types of listeners 1) Framework listener for global events related to the server 2) Bundle listener for events related to the deployments 3) Service listener for events related services Where these already exist, these need to be "adapted" to the OSGi api. The missing notifications need to be implemented. -- 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, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBOSGI-4) Deployer changes for OSGi

by Adrian Brock (JIRA)

Deployer changes for OSGi ------------------------- Key: JBOSGI-4 URL: http://jira.jboss.com/jira/browse/JBOSGI-4 Project: JBoss OSGi Issue Type: Task Security Level: Public (Everyone can see) Reporter: Adrian Brock Assigned To: Adrian Brock This is a holder task for the Deployer changes need to make OSGi work and integrate OSGi bundles with other JBoss deployments (and vice versa). -- 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, 4 months

2
2
0 / 0

[JBoss JIRA] Created: (JBOSGI-7) OSGi ClassLoader

by Adrian Brock (JIRA)

OSGi ClassLoader ---------------- Key: JBOSGI-7 URL: http://jira.jboss.com/jira/browse/JBOSGI-7 Project: JBoss OSGi Issue Type: Task Security Level: Public (Everyone can see) Reporter: Adrian Brock Assigned To: Adrian Brock Implementation of the OSGi classloader. This should be usable for both OSGi bundles and all other JBoss deployments. An new classloader.xml will be supported such that non OSGi deployments can specify their classloading constraints (import, export, etc.) Additionally, it should provide support for things outside the OSGi spec that are required in JavaEE or for backwards compatibility like scoping and j2se classloading compliance. -- 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, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBOSGI-15) Create a concrete subclass of the VFSClassLoaderPolicy that has injectable policy

by Adrian Brock (JIRA)

Create a concrete subclass of the VFSClassLoaderPolicy that has injectable policy --------------------------------------------------------------------------------- Key: JBOSGI-15 URL: http://jira.jboss.com/jira/browse/JBOSGI-15 Project: JBoss OSGi Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Other Reporter: Adrian Brock Assigned To: Adrian Brock Once the VFSClassLoader is done JBOSGI-14, we need to create a concrete subclass that allows injectable policy. i.e. setters. This will be used by the both JBossAS and OSGi through the Deployer layer to construct classloaders from the classloading dependencies/rules they define. -- 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, 4 months

1
4
0 / 0

[JBoss JIRA] Created: (JGRP-444) RequestCorrelator does not respect FLUSH.FlushHeader.BYPASS_FLUSH

by Michael Newcomb (JIRA)

RequestCorrelator does not respect FLUSH.FlushHeader.BYPASS_FLUSH ----------------------------------------------------------------- Key: JGRP-444 URL: http://jira.jboss.com/jira/browse/JGRP-444 Project: JGroups Issue Type: Bug Affects Versions: 2.5 Environment: 2.5 alpha 2 Reporter: Michael Newcomb Assigned To: Bela Ban private void handleRequest(Message req, Header hdr) { ... rsp=req.makeReply(); if(rsp_buf != null) rsp.setBuffer(rsp_buf); rsp_hdr=new Header(Header.RSP, hdr.id, false, name); rsp.putHeader(name, rsp_hdr); // *************** patch ***************** // can't check for FLUSH.FlushHeader.BYPASS_FLUSH because it has package protection, so just check for FLUSH header // if (req.getHeader(org.jgroups.protocols.pbcast.FLUSH.NAME) != null) { rsp.putHeader(org.jgroups.protocols.pbcast.FLUSH.NAME, new org.jgroups.protocols.pbcast.FLUSH.FlushHeader(org.jgroups.protocols.pbcast.FLUSH.FlushHeader.FLUSH_BYPASS)); } // *************** patch ***************** if(log.isTraceEnabled()) log.trace(new StringBuffer("sending rsp for ").append(rsp_hdr.id).append(" to ").append(rsp.getDest())); ... } -- 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, 4 months

3
10
0 / 0

[JBoss JIRA] Created: (JBAS-4242) Port Hibernate depoyer to VDF

by Scott M Stark (JIRA)

Port Hibernate depoyer to VDF ----------------------------- Key: JBAS-4242 URL: http://jira.jboss.com/jira/browse/JBAS-4242 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Deployment services, Hibernate service Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Scott M Stark Assigned To: Steve Ebersole Fix For: JBossAS-5.0.0.Beta3 The current hibernate integration tests are broken in jboss5 trunk, and the deployer needs to be ported to the VDF (http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss5DeploymentFramework). This really should be done in concert with the ejb3 deployer refactoring as there should be minimal duplication of the various deployment aspects related to persistence. -- 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, 4 months

4
7
0 / 0

[JBoss JIRA] Created: (EJBTHREE-697) First concurrent call doesn't throw exception

by Carlo de Wolf (JIRA)

First concurrent call doesn't throw exception --------------------------------------------- Key: EJBTHREE-697 URL: http://jira.jboss.com/jira/browse/EJBTHREE-697 Project: EJB 3.0 Issue Type: Bug Affects Versions: EJB 3.0 RC8 - FD Reporter: Carlo de Wolf Priority: Critical Fix For: EJB 3.0 RC10 - FD Concurrency check is in the server interceptor, while identity is established in the proxy after the first call. So if the first call is concurrent no exception is thrown. (see unit test concurrent) -- 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, 4 months

2
6
0 / 0

[JBoss JIRA] Created: (JBAS-4434) Create tests of file locking in the deploy dir

by Brian Stansberry (JIRA)

Create tests of file locking in the deploy dir ---------------------------------------------- Key: JBAS-4434 URL: http://jira.jboss.com/jira/browse/JBAS-4434 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Brian Stansberry Need simple tests where different sorts of deployments are copied to deploy, allowed to deploy, and then deleted. Intent is to prove that the file in the deploy dir can be deleted; i.e. the deployment process doesn't create a file lock. Most AS tests today do deployments via the RMIAdaptor, an approach that doesn't detect file lock issues. See JBAS--4415 and EJBTHREE-969 for an example of where this broke down. The FarmService tests have to use a 'copy file to farm dir' approach, so they detected a file lock issue. But this kind of problem should be directly tested so it's easier to know when problems like EJBTHREE-969 creep in. Also the FarmService test only deploys one jar; if by chance it had been a war instead of an ejb jar, the problem would not have been detected, since the JBossWeb deployer would have handled the war before accepts() was called on the Ejb3Deployer. -- 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, 5 months

2
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 May 2007