March 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-9061) DataSouce schema uses incorrect name for JDBC driver

by John Bailey (JIRA)

DataSouce schema uses incorrect name for JDBC driver ---------------------------------------------------- Key: JBAS-9061 URL: https://issues.jboss.org/browse/JBAS-9061 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Reporter: John Bailey Priority: Critical Fix For: 7.0.0.Beta2 Currently the datasources subsystem uses an element named <module> to express the driver name for a data-source. This really should reflect what the value is. Something like <driver>. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-9183) Update to console 1.0.0.Beta3

by Heiko Braun (JIRA)

Update to console 1.0.0.Beta3 ----------------------------- Key: JBAS-9183 URL: https://issues.jboss.org/browse/JBAS-9183 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Web Console Reporter: Heiko Braun Assignee: Heiko Braun Fix For: 7.0.0.Beta2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-9187) Use the SubjectFactoryService in connector's services

by Stefano Maestri (JIRA)

Use the SubjectFactoryService in connector's services ----------------------------------------------------- Key: JBAS-9187 URL: https://issues.jboss.org/browse/JBAS-9187 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 7.0.0.Beta1 Reporter: Stefano Maestri Assignee: Stefano Maestri Fix For: 7.0.0.Beta2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1851) Failure to send changeRate message results in idle client

by Justin Bertram (JIRA)

Failure to send changeRate message results in idle client --------------------------------------------------------- Key: JBMESSAGING-1851 URL: https://issues.jboss.org/browse/JBMESSAGING-1851 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.SP3.CP09 Reporter: Justin Bertram Assignee: Yong Hao Gao If a client fails to send a changeRate message, e.g.: ERROR [org.jboss.jms.client.container.ClientConsumer] Failed to send changeRate message org.jboss.jms.exception.MessagingNetworkFailureException at org.jboss.jms.client.delegate.DelegateSupport.handleThrowable(DelegateSupport.java:245) at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:205) at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:160) at org.jboss.jms.client.delegate.ClientConsumerDelegate.org$jboss$jms$client$delegate$ClientConsumerDelegate$changeRate$aop(ClientConsumerDelegate.java:138) at org.jboss.jms.client.delegate.ClientConsumerDelegate$changeRate_N952316153687074823.invokeNext(ClientConsumerDelegate$changeRate_N952316153687074823.java) at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:92) at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105) at org.jboss.jms.client.delegate.ClientConsumerDelegate$changeRate_N952316153687074823.invokeNext(ClientConsumerDelegate$changeRate_N952316153687074823.java) at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:172) at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105) at org.jboss.jms.client.delegate.ClientConsumerDelegate$changeRate_N952316153687074823.invokeNext(ClientConsumerDelegate$changeRate_N952316153687074823.java) at org.jboss.jms.client.delegate.ClientConsumerDelegate.changeRate(ClientConsumerDelegate.java) at org.jboss.jms.client.container.ClientConsumer.sendChangeRateMessage(ClientConsumer.java:754) at org.jboss.jms.client.container.ClientConsumer.checkSendChangeRate(ClientConsumer.java:913) at org.jboss.jms.client.container.ClientConsumer.access$1300(ClientConsumer.java:56) at org.jboss.jms.client.container.ClientConsumer$ListenerRunner.run(ClientConsumer.java:1026) at org.jboss.messaging.util.OrderedExecutorFactory$ChildExecutor.run(OrderedExecutorFactory.java:104) 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) Caused by: java.rmi.MarshalException: Failed to communicate. Problem during marshalling/unmarshalling; nested exception is: java.io.EOFException at org.jboss.remoting.transport.socket.SocketClientInvoker.handleException(SocketClientInvoker.java:131) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.handleOtherException(MicroSocketClientInvoker.java:812) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:725) at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:458) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:141) at org.jboss.remoting.Client.invoke(Client.java:1935) at org.jboss.remoting.Client.invoke(Client.java:788) at org.jboss.remoting.Client.invoke(Client.java:776) at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189) ... 18 more Caused by: java.io.EOFException at java.io.DataInputStream.readInt(DataInputStream.java:375) at org.jboss.jms.wireformat.JMSWireFormat.read(JMSWireFormat.java:288) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:1036) at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:694) ... 24 more The server will never know that the client needs more messages. Therefore the client will just sit there idle while messages on the server accumulate in its subscription. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
9
0 / 0

[JBoss JIRA] Created: (JBSER-121) Unable to deserialize java.io.File in java 6

by Yannick Boucher (JIRA)

Unable to deserialize java.io.File in java 6 -------------------------------------------- Key: JBSER-121 URL: https://jira.jboss.org/browse/JBSER-121 Project: JBoss Serialization Issue Type: Bug Affects Versions: 1.0.3 GA Environment: Windows XP. Java jdk1.6.0_20 Reporter: Yannick Boucher Assignee: Clebert Suconic After investigation the implementation of File changed between java 5 & 6. The new implementation use ObjectInputStream.readFields() instead of ObjectInputStream.defaultReadObject(). After a little more investigation I found that any call to readFields() would throw an exception. -- 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 months

4
7
0 / 0

[JBoss JIRA] Created: (JBAS-9168) ArjunaTransactionManagerService should be splitted

by Stefano Maestri (JIRA)

ArjunaTransactionManagerService should be splitted -------------------------------------------------- Key: JBAS-9168 URL: https://issues.jboss.org/browse/JBAS-9168 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Transaction Manager Integration (Arjuna) Affects Versions: 7.0.0.Beta1, 7.0.0.Alpha1 Reporter: Stefano Maestri Assignee: David Lloyd Fix For: 7.0.0.Beta2 We need a separate service for com.arjuna.ats.jbossatx.jta.RecoveryManagerService since we need to inject its value in a JCA service -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

3
9
0 / 0

[JBoss JIRA] Created: (EJBTHREE-2240) FilesystemDeploymentService hangs during deploy and doesn't pick any subsequent deployments

by jaikiran pai (JIRA)

FilesystemDeploymentService hangs during deploy and doesn't pick any subsequent deployments ------------------------------------------------------------------------------------------- Key: EJBTHREE-2240 URL: https://issues.jboss.org/browse/EJBTHREE-2240 Project: EJB 3.0 Issue Type: Bug Environment: JBoss AS7 master Reporter: jaikiran pai Priority: Critical FilesystemDeploymentService hangs while deploying certain file system based deployments. The deployment being processed stays in .deploying marker state and any new deployments added (along with a .dodeploy) to the deployment folder do not get processed. Attached is a thread dump. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

5
12
0 / 0

[JBoss JIRA] Created: (LOGTOOL-12) Generated classes should be using a different logger method

by David Lloyd (JIRA)

Generated classes should be using a different logger method ----------------------------------------------------------- Key: LOGTOOL-12 URL: https://issues.jboss.org/browse/LOGTOOL-12 Project: Log Tool Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 1.0.0.Beta6 Right now the generated classes are using the errorf/warnf/etc. methods. However using these methods causes an incorrectly-reported source file name/line number/class name/method name in logs which use these formats. Instead, the logf and logv methods should be used. Specifically, this form: {noformat} logger.logf(FQCN, Level.INFO, cause, format, param1, param2, ...); {noformat} The FCQN should be a "private static final String" field defined in each logger class and initialized to "LoggerClassName.class.getName()". Be sure to import the org.jboss.logging.Logger.Level class either directly or use it via Logger. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBAS-9188) Implement support for nested EJBs & WARs in .sar archives

by Richard Opalka (JIRA)

Implement support for nested EJBs & WARs in .sar archives --------------------------------------------------------- Key: JBAS-9188 URL: https://issues.jboss.org/browse/JBAS-9188 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: EE Reporter: Richard Opalka Assignee: Richard Opalka <opalka> dmlloyd, please review - https://github.com/ropalka/jboss-as/tree/sar-nested-archives-support <dmlloyd> SAR nested archives, eh? not sure I like the sound of that :) <opalka> dmlloyd, I'm not sure too <dmlloyd> what is the motivation and what are the semantics? <opalka> dmlloyd, we have some legacy tests <opalka> dmlloyd, and I know that TX team uses .sar archives with nested WS JSE endpoints in it <opalka> dmlloyd, The tests we have simply include EJB & WAR WS endpoints <opalka> dmlloyd, in bundled separate archives inside .sar <dmlloyd> Nihility: what do you think <opalka> dmlloyd, If we're not going to support it it's fine with me too. But in such case I'd create JBAS jira and we'll mark it as won't fix and I'll exclude the tests with reference to that JIRA <dmlloyd> my concern is that right now all of our nested deployment code assumes the outer deployment is an EAR <opalka> dmlloyd, yes I know. In the past there used to be some problems with SAR <opalka> dmlloyd, for example JNDI doesn't work in web archives bundled in .sar in AS6 <opalka> dmlloyd, maybe U can see some issues here in AS7 too? <opalka> s/some/similar/ <opalka> dmlloyd, BTW, why do we have support for .sar archives? Was it really required/necessary? <Nihility> i have no problem with allowing sars to be nested children, as it doesnt really mean much but as deployments that contain children i think we need to discourage that <dmlloyd> opalka, basically we have SARs for compatibility purposes only. I'm not really that happy that we support them myself <opalka> Nihility, dmlloyd OK, I'll create feature request JBAS JIRA - implement support for nested EJBs & WARs in .sar archives and will mark it as rejected/won't fix ? <dmlloyd> yeah I think that's the thing to do, opalka. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBBUILD-662) Upgrade Nexus to 1.8.0.1

by Paul Gier (JIRA)

Upgrade Nexus to 1.8.0.1 ------------------------ Key: JBBUILD-662 URL: https://jira.jboss.org/browse/JBBUILD-662 Project: JBoss Build System Issue Type: Task Components: Artifact Repositories Reporter: Paul Gier Assignee: Paul Gier Fix For: Repository Support 2010 Upgrade to Nexus 1.8.0.1. We are currently using 1.7.1 -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

15 years, 3 months

2
8
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 March 2011