February 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-7968) Property order is not specified for type org.jboss.xnio.metadata.ChannelListenerMetaData bound to a sequence

by Alexey Loubyansky (JIRA)

Property order is not specified for type org.jboss.xnio.metadata.ChannelListenerMetaData bound to a sequence ------------------------------------------------------------------------------------------------------------ Key: JBAS-7968 URL: https://jira.jboss.org/jira/browse/JBAS-7968 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Affects Versions: JBossAS-6.0.0.M2 Reporter: Alexey Loubyansky Property order is not specified for type org.jboss.xnio.metadata.ChannelListenerMetaData bound to a sequence. Property order can be specified using @XmlType.propOrder or @XmlAccessorOrder. List of properties: listener executor at org.jboss.xnio.metadata.XnioMetaData.channelListeners at org.jboss.xnio.metadata.XnioMetaData -- 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

15 years

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-8481) *nio

by Frank Langelage (JIRA)

*nio ---- Key: JBAS-8481 URL: https://jira.jboss.org/browse/JBAS-8481 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 6.0.0.M5 Environment: JBoss svn checkout on Solaris 10 using Sun JDK 1.6.0_21. Reporter: Frank Langelage 22:00:07,984 WARNING [FileConfigurationParser] AIO wasn't located on this platform, it will fall back to using pure Java NIO. If your platform is Linux, install LibAIO to enable the AIO journal 22:01:02,245 WARNING [FileConfigurationParser] AIO wasn't located on this platform, it will fall back to using pure Java NIO. If your platform is Linux, install LibAIO to enable the AIO journal -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

3
5
0 / 0

[JBoss JIRA] Created: (JBAS-8626) QueuedPessimisticEJBLock released to early

by Judith Bürgstein (JIRA)

QueuedPessimisticEJBLock released to early ------------------------------------------ Key: JBAS-8626 URL: https://jira.jboss.org/browse/JBAS-8626 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: JBossAS-5.1.0.GA, JBossAS-3.2.7 Final Reporter: Judith Bürgstein Usecase: All xx, xy, yy and xz are representing readonly entitybean-methods and are called on one EntityBean. CMT required and reentrant true. The following methods are executed on the server in this order: Thread1: calls entitybean.xx Thread1: calls entitybean.xy Thread2: calls entitybean.yy -> has to wait for the QueuedPessimisticEJBLock Thread1: returns from entitybean.xy and frees the QueuedPessimisticEJBLock <--- BUG Thread2: gets the QueuedPessimisticEJBLock but doesn't get the NonReentrantLock Thread1: calls entitybean.xz -> has to wait for the QueuedPessimisticEJBLock and still holds the NonReentrantLock Result: Undetected deadlock between QueuedPessimisticEJBLock and NonReentrantLock. Our current workaround: Created a subclass of QueuedPessimisticEJBLock and override problematic method "endInvocation": public void endInvocation(Invocation P_mi) { Transaction F_tx = P_mi.getTransaction(); if (F_tx != null && F_tx.equals(getTransaction())) { EntityEnterpriseContext F_ctx = (EntityEnterpriseContext)P_mi.getEnterpriseContext(); if(F_ctx == null) { endTransaction(F_tx); } else if(F_ctx.hasTxSynchronization() == false) { NonReentrantLock F_mLock = F_ctx.getMethodLock(); if (F_mLock == null) { endTransaction(F_tx); } else { Object F_resourceHolder = F_mLock.getResourceHolder(); if (F_resourceHolder instanceof Thread && Thread.currentThread().equals(F_resourceHolder)) { // don't end the transaction, because we still own the // lock! } else if (F_resourceHolder instanceof Transaction && F_tx.equals(F_resourceHolder)) { // don't end the transaction, because we still own the // lock! } else { endTransaction(F_tx); } } } else { //hasTxSynchronization is true -> don't end the transaction } } } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

2
5
0 / 0

[JBoss JIRA] Created: (JBAS-8124) Memory Leak in JBossMQ with 2PC QueueSessions

by Rico Neubauer (JIRA)

Memory Leak in JBossMQ with 2PC QueueSessions --------------------------------------------- Key: JBAS-8124 URL: https://jira.jboss.org/browse/JBAS-8124 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JMS (JBossMQ) Affects Versions: JBossAS-4.2.3.GA Reporter: Rico Neubauer Assignee: Adrian Brock JBossMQ has a memory leak, which has the same symptoms as reported for JBoss Messaging in https://jira.jboss.org/browse/JBMESSAGING-638 and discussed in http://community.jboss.org/thread/128250. Problem is that when using a transacted QueueSession, when closing QueueSession#close invokes QueueSession#internalRollback to clean-up any unacknowledged messages, but also starts a new transaction, which is added to QueueConnection's SpyXAResourceProvider. Since this transaction is never committed or rolled-back, it stays for the lifetime of the QueueConnection, which can be like forever when cacheing the QueueConnection. Also see "Steps to Reproduce" Will attach MAT screenshot. This occurs in JBossMQ of 4.2.3, but also 4.0.5 (and probably all 4.x) I am aware of the EOL of JBoss 4.x, but will attach a proposed patch anyways. Possible workarounds: - Do not use transacted QueueSessions - Close and nullify the QueueConnection from time to time to let GC clean-up the leaked objects -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

3
8
0 / 0

[JBoss JIRA] Created: (JBAS-8039) Failed to start a JAXWS war deployment

by jay ZHAO (JIRA)

Failed to start a JAXWS war deployment --------------------------------------- Key: JBAS-8039 URL: https://jira.jboss.org/browse/JBAS-8039 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.0.M2, JBossAS-5.1.0.GA Environment: RHEL Reporter: jay ZHAO We have a JAXWS war file which has been successfully deployed to GlassFish, WebSphere and WebLogic, but cannot be deployed to JBoss AS 5.1 and 6.0.0.M2. Here are the errors: 2010-05-19 10:32:09,746 ERROR [org.rhq.plugins.jbossas5.deploy.LocalDeployer] (ResourceContainer.invoker.nonDaemon-5) Error deploying application for request [CreateResourceReport: ResourceType=[ResourceType[id=0, category=Service, name=Web Application (WAR), plugin=JBossAS5]], ResourceKey=[null]].: java.lang.Exception: Failed to start deployment [vfszip:/opt/jboss-6.0.0.20100216-M2/server/default/deploy/JAXWSDiscoveryService.war/] during deployment of 'JAXWSDiscoveryService.war' - cause: java.lang.RuntimeException:org.jboss.deployers.spi.DeploymentException: Deployment context not found: vfszip:/opt/jboss-6.0.0.20100216-M2/server/default/deploy/JAXWSDiscoveryService.war/ -> : vfszip:/opt/jboss-6.0.0.20100216-M2/server/default/deploy/JAXWSDiscoveryService.war/ at org.rhq.plugins.jbossas5.util.DeploymentUtils.deployArchive(DeploymentUtils.java:146) at org.rhq.plugins.jbossas5.deploy.AbstractDeployer.deploy(AbstractDeployer.java:110) at org.rhq.plugins.jbossas5.ApplicationServerComponent.createContentBasedResource(ApplicationServerComponent.java:473) at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:295) 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:597) at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) We are not sure what deployment context means here and what Jboss is expected. We don't have jboss-web.xml file in war file. We could not find a clear instruction on whether we need jboss-web.xml or not. Some of our war files without jboss-web.xml still can be deployed successfully, but some not. We also could not find a good instruction on how to create one if we need. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-7897) Implement new LoggingMonitor

by David Lloyd (JIRA)

Implement new LoggingMonitor ---------------------------- Key: JBAS-7897 URL: https://jira.jboss.org/jira/browse/JBAS-7897 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Other Reporter: David Lloyd Assignee: Jimmy Wilson Fix For: JBossAS-6.0.0.M4 -- 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

15 years

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-8526) Revise LoadBeanDeploymentArchiveTestCase

by Marius Bogoevici (JIRA)

Revise LoadBeanDeploymentArchiveTestCase ---------------------------------------- Key: JBAS-8526 URL: https://jira.jboss.org/browse/JBAS-8526 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 6.0.0.M5 Reporter: Marius Bogoevici Assignee: Marius Bogoevici Priority: Trivial -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-8806) JBoss 6: NotSerializableException org.jboss.resource.work.JBossWorkManager

by Petr H (JIRA)

JBoss 6: NotSerializableException org.jboss.resource.work.JBossWorkManager -------------------------------------------------------------------------- Key: JBAS-8806 URL: https://issues.jboss.org/browse/JBAS-8806 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: JCA service Affects Versions: 6.0.0.Final Reporter: Petr H Assignee: Jesper Pedersen Use of JBoss JCA WorkManager via JNDI throws java.io.NotSerializableException: org.jboss.resource.work.JBossWorkManager at JBossAS 6.0.0 Sample code (and known workaround) in the referenced forum thread. The currently known workaround is to use more direct approach but this introduces a direct dependency on the JBoss code. As this issue affects for example Spring Framework I'm affraid such workaround isn't sufficient here. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-7995) Option roleGroupSeperator in UsersRolesLoginModule is misspelled

by Raphael Parree (JIRA)

Option roleGroupSeperator in UsersRolesLoginModule is misspelled ---------------------------------------------------------------- Key: JBAS-7995 URL: https://jira.jboss.org/jira/browse/JBAS-7995 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-5.1.0.GA Reporter: Raphael Parree Assignee: Anil Saldhana The module option roleGroupSeperator in UsersRolesLoginModule is misspelled "Seperator" should be spelled "Separator" (with an "a"). Perhaps allow both roleGroupSeperator and roleGroupSeparator not to break existing code -- 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

15 years

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-8387) support injection for a servlet that is registered programmatically

by Marcel Kolsteren (JIRA)

support injection for a servlet that is registered programmatically ------------------------------------------------------------------- Key: JBAS-8387 URL: https://jira.jboss.org/browse/JBAS-8387 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Weld/CDI Affects Versions: 6.0.0.M4 Reporter: Marcel Kolsteren Assignee: Marius Bogoevici Injection of a CDI Managed Bean into a servlet works for servlets that are registered using web.xml, but fails for servlets that are registered using the addServlet() method of the servlet context. Supporting injection in both cases would be more consistent and more convenient for developers. In order to demonstrate this issue, I created an Arquillian test for a managed JBoss M4 application server. The test deploys a war-file that contains two servlets. Both servlets refer to the same servlet class. The servlet class is very simple: it has a field into which a request scoped bean is injected, and it reports to the client whether or not this field contains a null value. The first servlet is defined in the web.xml file, the second servlet is registered programmatically by calling ServletContext.addServlet. The test cases show that the first servlet works as expected. However, the second servlet detects a null value in the field that should contain an injected instance of the request scoped bean. Steps for reproduction: unpack the attached zip file export JAVA_HOME = <home of your JDK> export JBOSS_HOME = <root directory of your JBoss 6 M4 server> mvn test -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years

2
2
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 February 2011