July 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-4460) Speed up clustering test suite using ARQ custom containers

by Radoslav Husar (JIRA)

Radoslav Husar created AS7-4460: ----------------------------------- Summary: Speed up clustering test suite using ARQ custom containers Key: AS7-4460 URL: https://issues.jboss.org/browse/AS7-4460 Project: Application Server 7 Issue Type: Feature Request Components: Clustering, Test Suite Affects Versions: 7.1.1.Final Reporter: Radoslav Husar Assignee: Radoslav Husar Fix For: 7.1.2.Final-redhat1 Leveraging ARQ-850. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (AS7-1928) Allow deployments to get access to the META-INF folder of their dependency module

by Marius Bogoevici (JIRA)

Allow deployments to get access to the META-INF folder of their dependency module --------------------------------------------------------------------------------- Key: AS7-1928 URL: https://issues.jboss.org/browse/AS7-1928 Project: Application Server 7 Issue Type: Feature Request Affects Versions: 7.1.0.Alpha1 Reporter: Marius Bogoevici Priority: Critical Currently there is absolutely no mechanism (outside of manipulating dependencies programmatically through a subsystem) for deployments to get access to some META-INF/xyz files from a module that they declare as a dependency, except are in META-INF/services. This is a serious impediment when considering the installation of third party libraries as shared libraries (modules) in JBoss AS. Some frameworks may rely upon locating internal descriptors in META-INF, and if the libraries are installed as modules, the descriptors are not accessible to the framework. Essentially, there is no way of accessing resources under META-INF unless they are either services, or the library is packaged in the deployment. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

8
21
0 / 0

[JBoss JIRA] (AS7-2847) TS: Clustering tests cant be run for single test with -Dtest=

by Radoslav Husar (Created) (JIRA)

TS: Clustering tests cant be run for single test with -Dtest= ------------------------------------------------------------- Key: AS7-2847 URL: https://issues.jboss.org/browse/AS7-2847 Project: Application Server 7 Issue Type: Bug Components: Clustering, Documentation, Test Suite Affects Versions: 7.1.0.Beta1 Reporter: Radoslav Husar Assignee: Paul Ferraro Fix For: 7.1.0.CR1 Maybe I missed something? {code}./integration-tests.sh clean install -Dts.clust -Dts.noSmoke{code} works okay, but when I do: {code}./integration-tests.sh clean install -Dts.clust -Dts.noSmoke -Dtest=org.jboss.as.test.clustering.cluster.ClusteredWebTestCase.java{code} then I get: {code} ------------------------------------------------------- T E S T S ------------------------------------------------------- Running org.jboss.as.test.clustering.cluster.ClusteredWebTestCase Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.915 sec <<< FAILURE! Results : Tests in error: org.jboss.as.test.clustering.cluster.ClusteredWebTestCase: DeploymentScenario contains targets not matching any defined Container in the registry. clustering-udp-1. Possible causes are: No Deployable Container found on Classpath or your have defined a @org.jboss.arquillian.container.test.api.Deployment with a @org.jboss.arquillian.container.test.api.TargetsContainer value that does not match any found/configured Containers (see arquillian.xml container@qualifier) Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 {code} Thanks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

8
14
0 / 0

[JBoss JIRA] (AS7-4490) max-active-sessions doesn't force min-idle sessions to passivate resulting in IllegalStateException

by Radoslav Husar (JIRA)

Radoslav Husar created AS7-4490: ----------------------------------- Summary: max-active-sessions doesn't force min-idle sessions to passivate resulting in IllegalStateException Key: AS7-4490 URL: https://issues.jboss.org/browse/AS7-4490 Project: Application Server 7 Issue Type: Bug Components: Clustering Affects Versions: 7.1.1.Final Reporter: Radoslav Husar Assignee: Paul Ferraro When a new session is to be created but number of sessions already reached max-active-sessions, the sessions that are beyond min-idle are not forced to passivate. {noformat} <system-out>19:20:59,397 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/passivating].[org.jboss.as.test.clustering.single.web.SimpleServlet]] (http--127.0.0.1-8080-3) Servlet.service() for servlet org.jboss.as.test.clustering.single.web.SimpleServlet threw exception: java.lang.IllegalStateException: JBAS018075: Number of active sessions exceeds limit 20 trying to create session at org.jboss.as.web.session.DistributableSessionManager.createSessionInternal(DistributableSessionManager.java:594) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.jboss.as.web.session.DistributableSessionManager.createSession(DistributableSessionManager.java:559) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.apache.catalina.connector.Request.doGetSession(Request.java:2665) [jbossweb-7.0.14.Final.jar:] at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.14.Final.jar:] at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:841) [jbossweb-7.0.14.Final.jar:] at org.jboss.as.test.clustering.single.web.SimpleServlet.doGet(SimpleServlet.java:47) [classes:] at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.1.Final.jar:1.0.1.Final] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.14.Final.jar:] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.14.Final.jar:] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.14.Final.jar:] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.14.Final.jar:] at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:67) at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:48) at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:125) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:91) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:88) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:56) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.14.Final.jar:] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.14.Final.jar:] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.14.Final.jar:] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.14.Final.jar:] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.14.Final.jar:] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.14.Final.jar:] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931) [jbossweb-7.0.14.Final.jar:] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_29] {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
1
0 / 0

[JBoss JIRA] (AS7-2448) TS: Check logging

by Ondřej Chaloupka (Created) (JIRA)

TS: Check logging ------------------ Key: AS7-2448 URL: https://issues.jboss.org/browse/AS7-2448 Project: Application Server 7 Issue Type: Sub-task Reporter: Ondřej Chaloupka Assignee: Ondrej Zizka ./integration-tests.sh clean install -Dtest=org.jboss.as.test.integration.ejb.async.* -Dintegration.module -Dbasic.integration.tests -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

8
9
0 / 0

[JBoss JIRA] (AS7-2660) wsconsume command line tool: Option --target is ignored

by Andreas Reimer (Created) (JIRA)

wsconsume command line tool: Option --target is ignored ------------------------------------------------------- Key: AS7-2660 URL: https://issues.jboss.org/browse/AS7-2660 Project: Application Server 7 Issue Type: Bug Components: Web Services Affects Versions: 7.0.2.Final Reporter: Andreas Reimer Assignee: Alessio Soldano Priority: Minor wsconsume always generates the same code regardless of the -t or --target switch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
5
0 / 0

[JBoss JIRA] (AS7-4899) Datasource names starting with number are invalid and gets deleted

by Luca Molteni (JIRA)

Luca Molteni created AS7-4899: --------------------------------- Summary: Datasource names starting with number are invalid and gets deleted Key: AS7-4899 URL: https://issues.jboss.org/browse/AS7-4899 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.1.1.Final Reporter: Luca Molteni Copy the example datasource into something like <datasource jndi-name="java:jboss/datasources/18DS" pool-name="18DS" enabled="true" use-java-context="true"> <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url> <driver>h2</driver> <security> <user-name>sa</user-name> <password>sa</password> </security> </datasource> The datasource is not parsed correctly and gets deleted when refreshing using the console. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
2
0 / 0

[JBoss JIRA] (AS7-4240) NameNotFoundException thrown when trying to read java:*/env context in Servlet container.

by Robert Edgecombe (JIRA)

Robert Edgecombe created AS7-4240: ------------------------------------- Summary: NameNotFoundException thrown when trying to read java:*/env context in Servlet container. Key: AS7-4240 URL: https://issues.jboss.org/browse/AS7-4240 Project: Application Server 7 Issue Type: Bug Components: Naming Affects Versions: 7.1.1.Final Environment: Windows7 Enterprise x64 Intel Core 2 Duo Oracle Java jdk1.6.0_29 Reporter: Robert Edgecombe Assignee: John Bailey We have many J2EE 1.4 apps that need to be migrated from Oracle Application Server These applications rely on configuration using Environment Entries Most of the answers to issues I have read indicate that this is done using jboss-web.xml but this is not an acceptable solutin as it requires repackaging of the deployment artifact for different servers and different environments and is therefor contrary to the spirit (and I believe the letter) of the JavaEE spec. The documentation on this capability is either hidden or missing. I was tasked with working out how to use the JBOSS tools to configure these values and have been unable to do so. I modified the quickstart helloworld example to accept a value using the @Resource annotation and attempted to set this value using jboss-cli. After several attempts to guess how to do this I modified the servlet to walk down the context tree. This servlet throws a NameNotFoundException when trying to list the bindings at: * java:comp/env * java:app/env * java:module/env I have written the servlet to perform this walk in the following contexts: * Ithe initial context * java: * java:jboss * java:comp * java:module * java:app * java:global java:global seems to be able to accept values added using jboss-cli (not surprising) java:comp, java:module and java:app seem to return some of the expected values (eg ModuleName and AppName) but throw the exception when trying to list entries under */env The initial context and java: seem to display the entries added through jboss-cli Adding a Deployment descriptor (web.xml), that provides values for these entries, results in no entries that are visible through jboss-cli or any of the contexts listed in the servlet. I then ran the following command through jboss-cli and restarted the app /profile=full/subsystem=naming/binding=\/java\:app\/jboss-as-helloworld-ear\/env\/GREETING_TEXT:add(binding-type="simple",value="RE") This resulted in the same NameNotFoundException being thrown at java:app/env when walking the initial context as has been thrown all along when listing env in java:app It also resulted in java:app appearing in the java: context but being empty. Prior to running the add command, java:app did not appear in the initial context or java: context at all. I then ran the following command through jboss-cli and restarted the app /profile=full/subsystem=naming/binding=\/java\:module\/jboss-as-helloworld-ear\/jboss-as-helloworld\/env\/GREETING_TEXT:add(binding-type="simple",value="SJM") This resulted in the same NameNotFoundException being thrown at java:module/env when walking the initial context as has been thrown all along when listing env in java:module It also resulted in java:module appearing in the java: context but being empty. Prior to running the add command, java:module did not appear in the initial context or java: context at all. My conclusion is that my commands in jboss-cli may be the appropriate ones to add the correct entries but that the servlet cannot reach the java:module/env or java:app/env contexts that should be available to it according to the javaEE6 spec. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

6
22
0 / 0

[JBoss JIRA] (AS7-5172) cannot define service activator in WAR META-INF, must be in WAR WEB-INF/classes/META-INF

by John Mazzitelli (JIRA)

John Mazzitelli created AS7-5172: ------------------------------------ Summary: cannot define service activator in WAR META-INF, must be in WAR WEB-INF/classes/META-INF Key: AS7-5172 URL: https://issues.jboss.org/browse/AS7-5172 Project: Application Server 7 Issue Type: Bug Affects Versions: 7.1.1.Final Reporter: John Mazzitelli Priority: Minor (note: I talked to dmlloyed on this in #jboss-as7 - he thinks its a bug, hence why I am filing this JIRA) I have a WAR. I want it to have a service activator in it (I want it to install an MSC service). So, in the WAR's META-INF directory, I create a "services/org.jboss.msc.service.ServiceActivator" file with the appropriate content. The service fails to activate. However, if I put that same META-INF content in my WAR's WEB-INF/classes directory (that is, my WAR has a WEB-INF/classes/META-INF/services/org.jboss.msc.service.ServiceActivator), my service activates fine. I will attach a .war file that you can use to test this. To see what I'm taking about, take the attached war and explode it inside the standalone/deployments directory in AS 7.1.1.Final. Run the app server - you will see in the output this: INFO [stdout] (MSC service thread 1-5) $$$$$$$$$$$$$$$$ SERVICE ACTIVATING! (this output comes from my ServiceActivator's activate() method - it does a System.out.println as soon as activate() is entered). This shows the WEB-INF/classes/META-INF/services being honored. Now shutdown the app server, cd to the deployments directory and cd down into the exploded war directory. Now move that services/ content directly up to the WAR's own META-INF directory: mv WEB-INF/classes/META-INF/services META-INF/ Now run the app server again. Notice you do NOT see the "SERVICE ACTIVATING" message. So it appears the WAR's META-INF/services is ignored when looking for service activators, but when the same services marker file is in WEB-INF/classes/META-INF/services, it works fine. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

4
11
0 / 0

[JBoss JIRA] (AS7-4962) NPE in HornetQ RA after MDB repeatedly throws exception

by Alexandre Gattiker (JIRA)

Alexandre Gattiker created AS7-4962: --------------------------------------- Summary: NPE in HornetQ RA after MDB repeatedly throws exception Key: AS7-4962 URL: https://issues.jboss.org/browse/AS7-4962 Project: Application Server 7 Issue Type: Bug Components: JMS Affects Versions: 7.1.1.Final Reporter: Alexandre Gattiker Assignee: Andy Taylor If an MDB throws a RuntimeException, after several redeliveries, following exception is thrown: Failed to call onMessage(): java.lang.NullPointerException at org.hornetq.ra.inflow.HornetQMessageHandler.onMessage(HornetQMessageHandler.java:336) at org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:983) [hornetq-core-2.2.13.Final.jar:] at org.hornetq.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:48) [hornetq-core-2.2.13.Final.jar:] at org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1113) [hornetq-core-2.2.13.Final.jar:] at org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100) [hornetq-core-2.2.13.Final.jar:] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_31] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_31] at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_31] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

3
5
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 July 2012