May 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (HIBERNATE-94) Determine which Hibernate dependencies are "supported" and "non-supported"

by Gail Badner (JIRA)

Determine which Hibernate dependencies are "supported" and "non-supported" -------------------------------------------------------------------------- Key: HIBERNATE-94 URL: http://jira.jboss.com/jira/browse/HIBERNATE-94 Project: Hibernate Issue Type: Sub-task Reporter: Gail Badner Assigned To: Gail Badner -- 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, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (HIBERNATE-96) Split distribution into separate source and binary distributions

by Gail Badner (JIRA)

Split distribution into separate source and binary distributions ---------------------------------------------------------------- Key: HIBERNATE-96 URL: http://jira.jboss.com/jira/browse/HIBERNATE-96 Project: Hibernate Issue Type: Sub-task Reporter: Gail Badner Assigned To: Gail Badner -- 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, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBASPECT-16) Test of jboss-aspects-test don't run

by Carlo de Wolf (JIRA)

Test of jboss-aspects-test don't run ------------------------------------ Key: JBASPECT-16 URL: http://jira.jboss.com/jira/browse/JBASPECT-16 Project: JBoss Aspects Issue Type: Bug Components: test Reporter: Carlo de Wolf Assigned To: Carlo de Wolf Priority: Blocker Fix For: 1.0.0.CR1 [INFO] Surefire report directory: /home/carlo/work/jboss-aspects/test/target/surefire-reports Exception in thread "main" java.lang.Error: Error transforming the class org.apache.maven.surefire.booter.SurefireBooter at org.jboss.aop.standalone.SystemClassLoader.loadClass(SystemClassLoader.java:199) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) Caused by: java.lang.NoClassDefFoundError: org/jboss/metadata/spi/signature/Signature at org.jboss.aop.AdvisorFactory.getClassAdvisor(AdvisorFactory.java:157) at org.jboss.aop.AdvisorFactory.getClassAdvisor(AdvisorFactory.java:105) at org.jboss.aop.SuperClassesFirstWeavingStrategy.instrumentClass(SuperClassesFirstWeavingStrategy.java:182) at org.jboss.aop.SuperClassesFirstWeavingStrategy.translate(SuperClassesFirstWeavingStrategy.java:70) at org.jboss.aop.AspectManager.translate(AspectManager.java:970) at org.jboss.aop.AspectManager.transform(AspectManager.java:916) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.aop.standalone.SystemClassLoader.loadClass(SystemClassLoader.java:179) ... 2 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, 2 months

1
4
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1362) Scope clustered SFSBs to the JBC /sfsb region

by Brian Stansberry (JIRA)

Scope clustered SFSBs to the JBC /sfsb region --------------------------------------------- Key: EJBTHREE-1362 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1362 Project: EJB 3.0 Issue Type: Task Components: cache, Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: AS 5.0.0.CR1 Don't just cache SFSBs under the cache root; put them in an /sfsb subtree. Helps keep them segregated from things like web sessions if we share the cache. -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1348) Use of replication queue and transactions may cause modifications not to be applied on remote nodes

by Manik Surtani (JIRA)

Use of replication queue and transactions may cause modifications not to be applied on remote nodes --------------------------------------------------------------------------------------------------- Key: JBCACHE-1348 URL: http://jira.jboss.com/jira/browse/JBCACHE-1348 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Replication, Transactions Affects Versions: 2.1.1.GA Reporter: Manik Surtani Assigned To: Manik Surtani Priority: Critical Fix For: 2.2.0.GA, 2.1.X When prepare method calls are created, they receive a reference to the modification list of the transaction. On transaction completion, however, the context is cleaned (JBCACHE-1326) which means the modification list is emptied. This was not a problem in 2.1.0 since 2.1.0 didn't scrub contexts after transaction completion (thus creating a class loader leak - see JBCACHE-1326). -- 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, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1364) StatelessContainer.isClustered() always returns false

by Brian Stansberry (JIRA)

StatelessContainer.isClustered() always returns false ----------------------------------------------------- Key: EJBTHREE-1364 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1364 Project: EJB 3.0 Issue Type: Bug Components: Clustering, core Affects Versions: AS 5.0.0.Beta4 Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: AS 5.0.0.CR1 Doesn't override the default method from Ejb3Container. -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCACHE-1332) Lock in eviction.Region:putNodeEvent()

by Nicolas Lebreton (JIRA)

Lock in eviction.Region:putNodeEvent() -------------------------------------- Key: JBCACHE-1332 URL: http://jira.jboss.com/jira/browse/JBCACHE-1332 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 1.4.1.SP1 Environment: JBoss 4.05 Hibernate 3.2.6.ga Reporter: Nicolas Lebreton Assigned To: Manik Surtani Priority: Critical JBoss TreeCache is used as cache provider. Please find attached jboss-service.xml configuration file. The second level cache is actitated, and several read-only classes are cacheable: <cache usage="read-only"/> The query cache is activated, and few queries are cacheable: <query name="ActorType.listAll.named" cacheable="true"> We encounter an issue. It can be reproduced on an environment with only few users connected (less than 10). For those users, screen is refreshed every 30 seconds through Ajax requests. Application is running in a cluster. On the other hand, this issue occurs with only one node started. A JBoss is started. Less than 24 hours later, application is becoming unresponsive. JBoss then needs to be recycled. And it works. Before stoping the node, I have taken several thread dumps separated by at least 30 seconds. Please find attached 10th, 11th, 25th's output files. We noticed thread locks in these 3 snapshots. The stack trace of the culprit was always the same (please see attached outputs for more details): # java.lang.Object:wait # waiting on-->EDU.oswego.cs.dl.util.concurrent.BoundedLinkedQueue(0x9331fd60) # java.lang.Object:wait(Object.java:474) # EDU.oswego.cs.dl.util.concurrent.BoundedLinkedQueue:put # locked-->EDU.oswego.cs.dl.util.concurrent.BoundedLinkedQueue(0x9331fd60) # locked-->java.lang.Object(0x9331fe78) # org.jboss.cache.eviction.Region:putNodeEvent(Region.java:141) # org.jboss.cache.interceptors.EvictionInterceptor:doEventUpdatesOnRegionManager(EvictionInterceptor.java:145) # org.jboss.cache.interceptors.EvictionInterceptor:updateNode(EvictionInterceptor.java:118) # org.jboss.cache.interceptors.EvictionInterceptor:invoke(EvictionInterceptor.java:93) Nicolas -- 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, 2 months

2
11
0 / 0

[JBoss JIRA] Created: (JBAS-5524) EAR isolation requires jboss-app.xml

by Alexey Loubyansky (JIRA)

EAR isolation requires jboss-app.xml ------------------------------------ Key: JBAS-5524 URL: http://jira.jboss.com/jira/browse/JBAS-5524 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.0.0.Beta4 Reporter: Alexey Loubyansky Assigned To: Alexey Loubyansky Fix For: JBossAS-5.0.0.CR1 Setting "isolated" to true in ear-deployer-beans.xml on JBossAppParsingDeployer will not make EARs isolated unless they include at least an empty jboss-app.xml. The bug is in the logic of JBossAppParsingDeployer.createMetaData(). The following patch would fix it @@ -152,6 +149,8 @@ if(specMetaData == null && metaData == null) return; + LoaderRepositoryConfig loaderCfg = null; + // If there no JBossMetaData was created from a jboss-app.xml, create one if (metaData == null) { @@ -160,12 +159,6 @@ else { LoaderRepositoryMetaData lrmd = metaData.getLoaderRepository(); - LoaderRepositoryConfig loaderCfg = null; - if (loaderCfg == null && isolated) - { - // If no config was given and isolation is on, create an isolated config - loaderCfg = initLoaderRepository(metaData, unit); - } if (lrmd != null) { loaderCfg = new LoaderRepositoryConfig(); @@ -189,10 +182,18 @@ loaderCfg.repositoryConfig = config.getConfig(); } } - // Add the loader repository config - if (loaderCfg != null) - unit.addAttachment(LoaderRepositoryConfig.class, loaderCfg); } + + if (loaderCfg == null && isolated) + { + // If no config was given and isolation is on, create an isolated config + loaderCfg = initLoaderRepository(metaData, unit); + } + + // Add the loader repository config + if (loaderCfg != null) + unit.addAttachment(LoaderRepositoryConfig.class, loaderCfg); -- 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, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-5525) NPE in JBossXSEntityResolver while deploying wsconsume generated WS

by Maximilian Schmidt (JIRA)

NPE in JBossXSEntityResolver while deploying wsconsume generated WS ------------------------------------------------------------------- Key: JBAS-5525 URL: http://jira.jboss.com/jira/browse/JBAS-5525 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA Environment: Recognized on Linux 2.6.24-16/x86 using Sun's JDK 1.5.0_07-b03 Reproduced on Windows Vista/x86 using Sun's JDK 1.5.0_14-b03 Reporter: Maximilian Schmidt Assigned To: Thomas Diesler Deploying a bottom-up webservice, which uses complex messages (compiled from eGIF/UBL2 schemas), results in a NPE as shown below: java.lang.NullPointerException at org.jboss.ws.metadata.wsdl.xmlschema.JBossXSEntityResolver.getXMLInputSource(JBossXSEntityResolver.java:167) at org.jboss.ws.metadata.wsdl.xmlschema.JBossXSEntityResolver.resolveEntity(JBossXSEntityResolver.java:135) at org.apache.xerces.impl.XMLEntityManager.resolveEntity(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaLoader.resolveDocument(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDHandler.resolveSchema(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDHandler.constructTrees(Unknown Source) at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source) at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown Source) at org.jboss.ws.tools.JavaToXSD.parseSchema(JavaToXSD.java:182) at org.jboss.ws.tools.wsdl.WSDL11Reader.processTypes(WSDL11Reader.java:391) at org.jboss.ws.tools.wsdl.WSDL11Reader.processTypes(WSDL11Reader.java:406) at org.jboss.ws.tools.wsdl.WSDL11Reader.processDefinition(WSDL11Reader.java:172) at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.parse(WSDLDefinitionsFactory.java:128) at org.jboss.ws.metadata.builder.jaxws.JAXWSWebServiceMetaDataBuilder.processOrGenerateWSDL(JAXWSWebServiceMetaDataBuilder.java:373) at org.jboss.ws.metadata.builder.jaxws.JAXWSWebServiceMetaDataBuilder.buildWebServiceMetaData(JAXWSWebServiceMetaDataBuilder.java:158) at org.jboss.ws.metadata.builder.jaxws.JAXWSServerMetaDataBuilder.setupProviderOrWebService(JAXWSServerMetaDataBuilder.java:50) at org.jboss.ws.metadata.builder.jaxws.JAXWSMetaDataBuilderJSE.buildMetaData(JAXWSMetaDataBuilderJSE.java:63) at org.jboss.wsf.stack.jbws.UnifiedMetaDataDeploymentAspect.create(UnifiedMetaDataDeploymentAspect.java:66) at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:115) at org.jboss.wsf.container.jboss42.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:97) at org.jboss.wsf.container.jboss42.DeployerInterceptor.start(DeployerInterceptor.java:90) at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.start(SubDeployerInterceptorSupport.java:188) at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterceptor.java:95) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy45.start(Unknown Source) at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819) at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782) at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210) at $Proxy9.deploy(Unknown Source) at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421) at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:610) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.loop(AbstractDeploymentScanner.java:274) at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.run(AbstractDeploymentScanner.java:225) Generating a WSDL from classes using wsprovide and afterwards way back to code using wsconsume results in a web service that on deployment produces the very same error, although wsprovide/wsconsume work flawlessly. See the mentioned forum thread for more information or take a look at http://page.mi.fu-berlin.de/schmidtm/jbossws-jaxb/ where the mentioned WSDL along with an eclipse/ant project that generates a deployable WAR can be found and used to reproduce the problem. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1363) Create EJB3 Common Project

by Andrew Lee Rubinger (JIRA)

Create EJB3 Common Project -------------------------- Key: EJBTHREE-1363 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1363 Project: EJB 3.0 Issue Type: Task Reporter: Andrew Lee Rubinger Assigned To: Andrew Lee Rubinger Fix For: AS 5.0.0.CR1 EJB3 Core defines a set of Utilities / Helpers that have crosscutting applicability among more than one EJB3 Component. Create a Common project such that these utilities may be centralized. -- 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, 2 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 May 2008