January 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-8831) hsqldb-ds.xml connection-url configuration for server mode results in null connection-url

by jaikiran pai (JIRA)

hsqldb-ds.xml connection-url configuration for server mode results in null connection-url ----------------------------------------------------------------------------------------- Key: JBAS-8831 URL: https://issues.jboss.org/browse/JBAS-8831 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.0.Final Reporter: jaikiran pai Assignee: Ales Justin The hsqldb-ds.xml has sections which need to be uncommented (and some commented) to enable server mode HSQL DB server. Additionally, a section in the bindings-jboss-beans.xml in JBOSS_HOME/server/<servername>/conf/bindingservice.beans needs to be uncommented too. The part which fails is: <connection-url> <value-factory bean="ServiceBindingManager" method="getStringBinding"> <parameter>jboss:service=Hypersonic</parameter> <parameter>jdbc:hsqldb:hsql://${host}:${port}</parameter> </value-factory> </connection-url> The exception is: Caused by: org.jboss.resource.JBossResourceException: connectionURL is null at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createConnectionFactory(LocalManagedConnectionFactory.java:90) [:6.0.0.Final] at org.jboss.resource.connectionmanager.ConnectionFactoryBindingService.createConnectionFactory(ConnectionFactoryBindingService.java:141) [:6.0.0.Final] ... 79 more The root cause is that the code ends up calling the wrong method on ServiceBindingManger. Instead of calling the getStringBinding with 2 parameters, it ends up calling the getStringBinding with just the single (service name) parameter. The code which parses the parameters, is in org.jboss.system.metadata.ServiceMetaDataParser: private ServiceValueMetaData parseValueFactory(Element el) throws Exception { ... List<ServiceValueFactoryParameterMetaData> parameters = new ArrayList<ServiceValueFactoryParameterMetaData>(); attr = el.getAttributeNode("parameter"); if (attr != null) { parameters.add(new ServiceValueFactoryParameterMetaData(attr.getValue())); } else { NodeList children = el.getChildNodes(); for (int j = 0; j < children.getLength(); j++) { // skip over non-element nodes if (children.item(j).getNodeType() != Node.ELEMENT_NODE) continue; Element child = (Element) children.item(j); if ("parameter".equals(child.getTagName())) { parameters.add(parseValueFactoryParameter(child)); } } } .... The code never enters the else part for that above xml configuration. I haven't looked into the details of that getAttributeNode API, but it appears like a bug to me in the xerces impl (i might be wrong), since "parameter" isn't really an attribute. Assigning this to Ales for now, since that class lies within jboss-jmx-mc-int project. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
7
0 / 0

[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

13 years, 9 months

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

13 years, 9 months

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

13 years, 9 months

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

13 years, 9 months

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

13 years, 9 months

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

13 years, 9 months

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

13 years, 9 months

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

13 years, 9 months

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

13 years, 9 months

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2011