August 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (AS7-1502) Invalid <useFastFail> element written out to datasource configuration

by jaikiran pai (JIRA)

Invalid <useFastFail> element written out to datasource configuration --------------------------------------------------------------------- Key: AS7-1502 URL: https://issues.jboss.org/browse/AS7-1502 Project: Application Server 7 Issue Type: Bug Components: JCA Environment: Latest AS7 upstream Reporter: jaikiran pai Assignee: Jesper Pedersen Fix For: 7.0.1.Final By default the standalone.xml doesn't have an empty validation configuration for datasources. {code} <validation></validation> {code} But management operations (which maybe unrelated to datasources) lead to the following (invalid) xml content. Note the <useFastFail> element which isn't a valid element. The xsd allows use-fast-fail instead {code} <validation> <validate-on-match> false </validate-on-match> <background-validation> false </background-validation> <useFastFail> false </useFastFail> </validation> </datasource> {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (AS7-1242) arquillian-service is only deployed to first container in group

by Dan Allen (JIRA)

arquillian-service is only deployed to first container in group --------------------------------------------------------------- Key: AS7-1242 URL: https://issues.jboss.org/browse/AS7-1242 Project: Application Server 7 Issue Type: Bug Components: Test Suite Affects Versions: 7.0.0.CR1 Reporter: Dan Allen When using the Arquillian group feature with the JBoss AS 7 remote container adapter, the arquillian-service is only deployed to the first container. For an example of the problem, see the multinode example in the Arquillian showcase [1]. The test only runs if I use servers that already have the arquillian-service deployed. http://github.com/arquillian/arquillian-showcase -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

3
4
0 / 0

[JBoss JIRA] Created: (AS7-1503) Incorrect handling of resource adapter name with .rar extension

by jaikiran pai (JIRA)

Incorrect handling of resource adapter name with .rar extension --------------------------------------------------------------- Key: AS7-1503 URL: https://issues.jboss.org/browse/AS7-1503 Project: Application Server 7 Issue Type: Bug Components: EJB Environment: Latest AS7 upstream Reporter: jaikiran pai Assignee: jaikiran pai Fix For: 7.0.1.Final Using @ResourceAdapterName(value="twitter-ra.rar") (note the .rar extension) results in a twitter-ra not being found (even if it's deployed). See the referenced forum thread for details. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
0
0 / 0

[JBoss JIRA] Commented: (AS7-1485) Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory

by jaikiran pai (JIRA)

[ https://issues.jboss.org/browse/AS7-1485?page=com.atlassian.jira.plugin.s... ] jaikiran pai commented on AS7-1485: ----------------------------------- Note that we have a specific test for this in AS7 https://github.com/jbossas/jboss-as/blob/master/testsuite/integration/src.... We need to include JSF 1.2 in that test. Jason had patched Xerces and JSF2 (Mojarra) in AS7 to get this working. > Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory > ------------------------------------------------------------------------- > > Key: AS7-1485 > URL: https://issues.jboss.org/browse/AS7-1485 > Project: Application Server 7 > Issue Type: Bug > Components: JSF > Affects Versions: 7.0.0.Final > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Fix For: Open To Community > > > Packaging Xerces in war causes JSF ClassCastException on SAXParserFactory > ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost]. (main) Exception sending context initialized event to listener instance of class org.jboss.web.jsf.integration.config.JBossJSFConfigureListener > java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl cannot be cast to javax.xml.parsers.SAXParserFactory > at javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:128) > at com.sun.faces.config.ConfigureListener$WebXmlProcessor.getConfiguredFactory(ConfigureListener.java:702) > at com.sun.faces.config.ConfigureListener$WebXmlProcessor.scanForFacesServlet(ConfigureListener.java:674) > at com.sun.faces.config.ConfigureListener$WebXmlProcessor.<init>(ConfigureListener.java:648) > at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:156) > at org.jboss.web.jsf.integration.config.JBossJSFConfigureListener.contextInitialized(JBossJSFConfigureListener.java:60) > at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3910) > at org.apache.catalina.core.StandardContext.start(StandardContext.java:4389) > at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:321) > at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:145) > at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461) > at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-3136) Exception when extending non-bean classes

by Davide Sottara (JIRA)

Exception when extending non-bean classes ----------------------------------------- Key: JBRULES-3136 URL: https://issues.jboss.org/browse/JBRULES-3136 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 5.2.0.Final Reporter: Davide Sottara Assignee: Mark Proctor Fix For: 5.3.0.Beta1 When a declared class extends another, the compiler looks for fields in the superclass using the getter methods, which are then reused by the internal field readers/writers. When a superclass has a field with a getter only (i.e. no setter), an exception is thrown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2784) Use java-style annotations for metadata

by Davide Sottara (JIRA)

Use java-style annotations for metadata ---------------------------------------- Key: JBRULES-2784 URL: https://jira.jboss.org/browse/JBRULES-2784 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.2.0.M1 Reporter: Davide Sottara Assignee: Mark Proctor Priority: Trivial Fix For: 5.2.0.M1 Drools Metadata, allowed in rules and bean declarations, are conceptually similar to java annotations, but the actual structure is different: Drools is free-form, while Java uses (optional) key - element pairs: Drools : @attr( <free text here> ) Java : @attr( key1 = value1, key2 ... ) I suggest the use of Java-like annotations in place of free-form meta-attributes. Compatibility with official metadata (e.g. event definition) will be guaranteed. Could break compatibility if a user defined and used their own metadata in the code, as some constructs like @author(john doe) will no longer be accepted, even if @author("john doe"), @author(john, doe) or @author(name="john doe") will. -- 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

14 years, 10 months

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-3104) Use annotations on declared beans

by Davide Sottara (JIRA)

Use annotations on declared beans --------------------------------- Key: JBRULES-3104 URL: https://issues.jboss.org/browse/JBRULES-3104 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.2.0.Final Reporter: Davide Sottara Assignee: Mark Proctor Priority: Minor Fix For: 5.3.0.Beta1 When declaring beans (i.e. using the "declare" feature), if metadata attached to a class or a field corresponds to an actual @Annotation, that @Annotation should be present in the generated class. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
2
0 / 0

[JBoss JIRA] Created: (AS7-1483) After so many deployments subsequent deployments are not deployed.

by Darran Lofthouse (JIRA)

After so many deployments subsequent deployments are not deployed. ------------------------------------------------------------------ Key: AS7-1483 URL: https://issues.jboss.org/browse/AS7-1483 Project: Application Server 7 Issue Type: Bug Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 7.0.1.Final To test the changes for AS7-1473 added a temporary test to ServerInModuleDeploymentTestCase to loop 50 times and call each of the filesystem based test cases. Almost at the end the marker based test is being executed and the deployment requested to be deployed, the scanner picks this up and the following is logged: - {noformat} 16:50:42,027 DEBUG [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Deployment scan of [/home/darranl/src/jbossas7/jboss-as/testsuite/smoke/target/marker-deployments] found update action [{ "operation" => "composite", "address" => undefined, "steps" => [ { "operation" => "add", "address" => [("deployment" => "test-deployment.sar")], "content" => [{ "path" => "/home/darranl/src/jbossas7/jboss-as/testsuite/smoke/target/marker-deployments/test-deployment.sar", "archive" => true }], "persistent" => false }, { "operation" => "deploy", "address" => [("deployment" => "test-deployment.sar")] } ] }] {noformat} However the deployment is not logged and there is no further logging in relation to this scan. It appears however that the thread continues to be used for subsequent scans. {noformat} 16:50:46,997 TRACE [org.jboss.as.deployment] (DeploymentScanner-threads - 1) Scanning directory /home/darranl/src/jbossas7/jboss-as/testsuite/smoke/target/jbossas/standalone/deployments for deployment content changes {noformat} Reviewing the thread dump shows no threads blocked in a call to scan within FileSystemDeploymentService. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (AS7-1499) Issue with legacy <ejb-local-ref> lookup from a WAR

by Robert Baty (JIRA)

Issue with legacy <ejb-local-ref> lookup from a WAR --------------------------------------------------- Key: AS7-1499 URL: https://issues.jboss.org/browse/AS7-1499 Project: Application Server 7 Issue Type: Bug Components: EJB Affects Versions: 7.0.0.Final Environment: JBossAS 7.0.0.Final on a Windows developer desktop. Reporter: Robert Baty Assignee: Carlo de Wolf Trying to deploy an application that consists of a EAR/WAR/EJB module all separate. In the WAR a reference to the EJB3 SLSB is done like this: <ejb-local-ref> <ejb-ref-name>ejb/OrderResource</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <local>rjb.rest.restfully.services.ejb.basic.OrderResource</local> <ejb-link>OrderResourceBean</ejb-link> </ejb-local-ref> And then in a WAR Listener class a lookup is done on an InitialContext like this: InitialContext ic = new InitialContext(); Object orderResourceLocalProxy = context.lookup("java:comp/env/ejb/OrderResource"); Seems to cause an exception so the application does not deploy. The stack trace is below: 15:58:51,638 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.subunit."RJBatyRESTEAR-1.2.ear"."RJBatyREST-1.2.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."RJBatyRESTEAR-1.2.ear"."RJBatyREST-1.2.war".POST_MODULE: Failed to process phase POST_MODULE of subdeployment "RJBatyREST-1.2.war" of deployment "RJBatyRESTEAR-1.2.ear" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765) at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) [:1.6.0_21] at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [:1.6.0_21] at java.lang.Thread.run(Unknown Source) [:1.6.0_21] Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Could not determine type of ejb-local-ref java:module/env/ejb/OrderResource for component null at org.jboss.as.ejb3.deployment.processors.EjbRefProcessor.processDescriptorEntries(EjbRefProcessor.java:93) at org.jboss.as.ee.component.AbstractDeploymentDescriptorBindingsProcessor.deploy(AbstractDeploymentDescriptorBindingsProcessor.java:60) at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) ... 5 more -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBVFS-160) FileSystemContext.getFileURI returns wrong URI for UNC paths on Windows

by James Livingston (JIRA)

FileSystemContext.getFileURI returns wrong URI for UNC paths on Windows ----------------------------------------------------------------------- Key: JBVFS-160 URL: https://jira.jboss.org/browse/JBVFS-160 Project: JBoss VFS Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.1.3.SP1 Environment: Windows Reporter: James Livingston Assignee: John Bailey Attachments: UncPathTest.java When passed a File for something with a UNC path (e.g. \\127.0.0.1\shared), FileSystemContext.getFileURI() return a URI like "file://127.0.0.1/shared" (which is what Windows itself uses) rather than "file:////127.0.0.1/shared" (which Java uses, and converts for OS calls). This will cause JBoss to fail to deploy things if they are located on an unmapped UNC location. I'm attaching a test case for this. To use it, you need to run it on a Windows system and have access to a something with a UNC path. The code as written expects there to be a SMB share called "shared" on the machine it is run on, but it can easily be change to point elsewhere. -- 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

14 years, 10 months

3
12
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 August 2011