[JBoss JIRA] (AS7-3085) Deployment breaks when data source is being recycled
by Heiko Braun (Created) (JIRA)
Deployment breaks when data source is being recycled
----------------------------------------------------
Key: AS7-3085
URL: https://issues.jboss.org/browse/AS7-3085
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Heiko Braun
Assignee: Brian Stansberry
Fix For: 7.1.0.Final
Deploy the jboss-as-login.war example. It depends on the "ExampleDS" datasource. Access the web application. Disable and enable the datasource. Try the web app again:
{noformat}
13:11:26,599 INFO [org.jboss.as.controller] (HttpManagementService-threads - 4) JBAS014774: Service status report
JBAS014776: Newly corrected services:
service jboss.naming.context.java.jboss.datasources.ExampleDS (no longer required)
{noformat}
This error prevails as long as the deployment is not disabled and re-eanbled again
--
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
12 years, 5 months
[JBoss JIRA] (AS7-2505) Deployment order for MDBs and RAs is not working for a packaged EAR
by Abhi S (Created) (JIRA)
Deployment order for MDBs and RAs is not working for a packaged EAR
-------------------------------------------------------------------
Key: AS7-2505
URL: https://issues.jboss.org/browse/AS7-2505
Project: Application Server 7
Issue Type: Bug
Components: Deployment, EJB, JCA
Affects Versions: 7.1.0.Alpha1, 7.0.2.Final
Environment: Windows 7 64-bit
Reporter: Abhi S
Assignee: Thomas Diesler
Priority: Critical
If an application is packaged with MDBs and RAs (resource adapters) such that the order of deployment of these modules needs to be deterministic, the application fails to load. In other words, there is no way to define the order in which MDBs and RAs must be loaded in an application. This is a strict requirement by JEE 6, and without this support, JBoss 7 cannot be fully JEE 6 compliant.
Theoretically, following are 3 different ways to accomplish the above objective:
# Set <initialize-in-order> to true; see http://java.sun.com/xml/ns/javaee/application_6.xsd. This seems to be fixed in AS7-325, but I tested it using a sample application, and this definitely does not work for MDBs and RAs.
# Add jboss-ejb3.xml in the MDB jar's MATA-INF to define the MDB's dependency on an RA. Adding this configuration MUST ensure that the application loader loads the RA before trying to load the MDB.
# Add org.jboss.ejb3.annotation.Depends annotation on the MDB implementation, to do the same as #2.
None of the above work in the nightly build of AS7.1.
--
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
12 years, 5 months
[JBoss JIRA] (AS7-3162) RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath
by Pavel Janousek (Closed) (JIRA)
[ https://issues.jboss.org/browse/AS7-3162?page=com.atlassian.jira.plugin.s... ]
Pavel Janousek closed AS7-3162.
-------------------------------
Resolution: Rejected
I rejected this issue due to probably miss-understanding specific piece of JAX-RS specification. Valid deployment is left in [this|https://issues.jboss.org/browse/AS7-3162?focusedCommentId=12654051&p...] comment.
> RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-3162
> URL: https://issues.jboss.org/browse/AS7-3162
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Weinan Li
> Priority: Blocker
>
> I've deployment like this:
> {code}
> @Deployment
> public static Archive<?> deploy() {
> WebArchive war = ShrinkWrap.create(WebArchive.class, "jaxrsnoap.war");
> war.addPackage(HttpRequest.class.getPackage());
> war.addClasses(ApplicationTestCase.class, ApplicationInvalid1.class);
> war.addAsWebInfResource(
> WebXml.get("<servlet-mapping>\n"
> + " <servlet-name>javax.ws.rs.core.Application</servlet-name>\n"
> + " <url-pattern>/myjaxrs/*</url-pattern>\n"
> + "</servlet-mapping>\n" + "\n"), "web.xml");
> return war;
> }
> {code}
> This deployment fails during deploying because of "Context [/jaxrsnoap] startup failed due to previous errors: java.lang.IllegalArgumentException: Servlet mapping specifies an unknown servlet name javax.ws.rs.core.Application"
> ApplicationInvalid1 is empty subclass of javax.ws.rs.core.Application like:
> {code}
> public class ApplicationInvalid1 extends Application {
> private Set<Class<?>> classes = new HashSet<Class<?>>();
> public ApplicationInvalid1() {
> }
> @Override
> public Set<Class<?>> getClasses() {
> return classes;
> }
> }
> {code}
> There isn't any reference to this class in web.xml or somewhere else. Only class is placed on classpath. If I remove this class from deployment (= change appropriate line to "war.addClasses(ApplicationTestCase.class);", everything will be OK.
--
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
12 years, 5 months
[JBoss JIRA] (AS7-3162) RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath
by Pavel Janousek (Commented) (JIRA)
[ https://issues.jboss.org/browse/AS7-3162?page=com.atlassian.jira.plugin.s... ]
Pavel Janousek commented on AS7-3162:
-------------------------------------
Hi Weinen, you are right only partially.
My primary goal was finding the way how to do servlet-mapping in web.xml (not via annotation) and use the +portable+ way - not locking to concrete JAX-RS implementation. I thought this way is to specify servlet-mapping via reserved key (servlet-name) javax.ws.rs.Application or javax.ws.rs.core.Application. This was really bad idea.
But my previous example/deployment from [there|https://issues.jboss.org/browse/AS7-3162?focusedCommentId=12653831&...] is valid, I'm missing only definition of servlet-name org.jboss.as.test.integration.jaxrs.deployments.ApplicatonEmptyWithoutAOP. This is Servlet 3.0 feature - omit servlet-class in this way.
So you don't need annotation and can use servlet-mapping via fully qualified class name, but it seems you must define servlet-name yourself - I understood Stuarts citation from JAX-RS specs as requirement for JAX-RS implementation in this case - never mind.
So Application class can stay untouched, but deployment must be modified to this:{code}<?xml version=1.0 encoding="UTF-8"?>
<web-app version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" metadata-complete="false">
<servlet>
<servlet-name>org.jboss.as.test.integration.jaxrs.deployments.ApplicatonEmptyWithoutAOP</servlet-name>
</servlet>
<servlet-mapping>
<servlet-name>org.jboss.as.test.integration.jaxrs.deployments.ApplicatonEmptyWithoutAOP</servlet-name>
<url-pattern>/myjaxrs/*</url-pattern>
</servlet-mapping>
</web-app>{code}
Sure, this way is also supported by RESTEasy and it works too:-).
Anyway - topic about mixing annotation and web.xml mapping - there is section 8 in Servlet 3.0 specs, where everything about these topics is described. Very shortly - web.xml mapping has higher priority (= replaces annotation in conflicted states) and annotation is processed only when attribute metadata-complete of web-app element isn't set to true - this works too. I'm feeling mixing annotation and servlet-mapping primary as way for cooperation legacy code (annotation was introduced in Java 1.5 - so not many years ago as servlet technology) and AOP paradigm. Many servlets are implemented (and debugged) by old-school way and annotation modifications can enter many issues to them - we should take this in "QA mind":-) too.
> RESTEasy: Unknown servet name javax.ws.rs.core.Application when javax.ws.rs.core.Application subclass is on classpath
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-3162
> URL: https://issues.jboss.org/browse/AS7-3162
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Weinan Li
> Priority: Blocker
>
> I've deployment like this:
> {code}
> @Deployment
> public static Archive<?> deploy() {
> WebArchive war = ShrinkWrap.create(WebArchive.class, "jaxrsnoap.war");
> war.addPackage(HttpRequest.class.getPackage());
> war.addClasses(ApplicationTestCase.class, ApplicationInvalid1.class);
> war.addAsWebInfResource(
> WebXml.get("<servlet-mapping>\n"
> + " <servlet-name>javax.ws.rs.core.Application</servlet-name>\n"
> + " <url-pattern>/myjaxrs/*</url-pattern>\n"
> + "</servlet-mapping>\n" + "\n"), "web.xml");
> return war;
> }
> {code}
> This deployment fails during deploying because of "Context [/jaxrsnoap] startup failed due to previous errors: java.lang.IllegalArgumentException: Servlet mapping specifies an unknown servlet name javax.ws.rs.core.Application"
> ApplicationInvalid1 is empty subclass of javax.ws.rs.core.Application like:
> {code}
> public class ApplicationInvalid1 extends Application {
> private Set<Class<?>> classes = new HashSet<Class<?>>();
> public ApplicationInvalid1() {
> }
> @Override
> public Set<Class<?>> getClasses() {
> return classes;
> }
> }
> {code}
> There isn't any reference to this class in web.xml or somewhere else. Only class is placed on classpath. If I remove this class from deployment (= change appropriate line to "war.addClasses(ApplicationTestCase.class);", everything will be OK.
--
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
12 years, 5 months
[JBoss JIRA] (AS7-3200) Regression in executing EL-methods with parameters after upgrading from JBossWeb 7.0.4
by Nicklas Karlsson (Created) (JIRA)
Regression in executing EL-methods with parameters after upgrading from JBossWeb 7.0.4
--------------------------------------------------------------------------------------
Key: AS7-3200
URL: https://issues.jboss.org/browse/AS7-3200
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: 7.1.0.CR1b
Reporter: Nicklas Karlsson
Assignee: Remy Maucherat
I have a commandLink like
<ice:commandLink action="#{lukkoinfo.lukkoinfoHakija(tilaus.id.tilausnumero)}" immediate="true">x</ice:commandLink>
which worked fine for Beta1 but fails on upstream master. I bisected it down to the place where JBossWeb was upgraded from 7.0.4 to 7.0.5 where it fails.
The stack trace is
15:29:00,986 WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] (http--127.0.0.1-8080-1) #{lukkoinfo.lukkoinfoHakija(tilaus.id.tilausnumero)}: javax.el.MethodNotFoundException: /OSTi.xhtml @76,103 action="#{lukkoinfo.lukkoinfoHakija(tilaus.id.tilausnumero)}": Method not found: fi.affecto.osti.tilaus.lukitus.Lukkoinfo(a)6314a7a5.lukkoinfoHakija(java.lang.Integer): javax.faces.FacesException: #{lukkoinfo.lukkoinfoHakija(tilaus.id.tilausnumero)}: javax.el.MethodNotFoundException: /OSTi.xhtml @76,103 action="#{lukkoinfo.lukkoinfoHakija(tilaus.id.tilausnumero)}": Method not found: fi.affecto.osti.tilaus.lukitus.Lukkoinfo(a)6314a7a5.lukkoinfoHakija(java.lang.Integer)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:110) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:794) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at javax.faces.component.UIViewRoot.processDecodes(UIViewRoot.java:935) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.7.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.7.Final.jar:]
at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62) [weld-core-1.1.4.Final.jar:2011-11-22 20:01]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.7.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.7.Final.jar:]
at org.jboss.solder.servlet.exception.CatchExceptionFilter.doFilter(CatchExceptionFilter.java:65) [solder-impl-3.1.0.Beta4.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.7.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.7.Final.jar:]
at org.jboss.solder.servlet.event.ServletEventBridgeFilter.doFilter(ServletEventBridgeFilter.java:74) [solder-impl-3.1.0.Beta4.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.7.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.7.Final.jar:]
at fi.affecto.osti.fwkint.servlet.RollbackFilter.doFilter(RollbackFilter.java:34) [classes:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.7.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.7.Final.jar:]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.7.Final.jar:]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.7.Final.jar:]
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:151) [jboss-as-web-7.1.0.Final-SNAPSHOT.jar:7.1.0.Final-SNAPSHOT]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.7.Final.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.7.Final.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.7.Final.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.7.Final.jar:]
at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:897) [jbossweb-7.0.7.Final.jar:]
at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:626) [jbossweb-7.0.7.Final.jar:]
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:2033) [jbossweb-7.0.7.Final.jar:]
at java.lang.Thread.run(Thread.java:722) [:1.7.0]
Caused by: javax.faces.el.MethodNotFoundException: javax.el.MethodNotFoundException: /OSTi.xhtml @76,103 action="#{lukkoinfo.lukkoinfoHakija(tilaus.id.tilausnumero)}": Method not found: fi.affecto.osti.tilaus.lukitus.Lukkoinfo(a)6314a7a5.lukkoinfoHakija(java.lang.Integer)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:92) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
... 33 more
Caused by: javax.el.MethodNotFoundException: /OSTi.xhtml @76,103 action="#{lukkoinfo.lukkoinfoHakija(tilaus.id.tilausnumero)}": Method not found: fi.affecto.osti.tilaus.lukitus.Lukkoinfo(a)6314a7a5.lukkoinfoHakija(java.lang.Integer)
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:109) [jsf-impl-2.1.5-jbossorg-1.jar:2.1.5-SNAPSHOT]
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:88) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
... 34 more
--
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
12 years, 5 months
[JBoss JIRA] (AS7-3199) RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present
by Pavel Janousek (Moved) (JIRA)
[ https://issues.jboss.org/browse/AS7-3199?page=com.atlassian.jira.plugin.s... ]
Pavel Janousek moved JBPAPP-7858 to AS7-3199:
---------------------------------------------
Project: Application Server 7 (was: JBoss Enterprise Application Platform)
Key: AS7-3199 (was: JBPAPP-7858)
Workflow: GIT Pull Request workflow (was: jira)
Affects Version/s: 7.1.0.CR1b
(was: EAP 6.0.0 DR 9)
Component/s: REST
(was: RESTEasy)
Security: (was: JBoss Internal)
Docs QE Status: (was: NEW)
> RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present
> ---------------------------------------------------------------------------------------------
>
> Key: AS7-3199
> URL: https://issues.jboss.org/browse/AS7-3199
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Assignee: Weinan Li
> Priority: Blocker
> Attachments: ExampleJAXRS.war
>
>
> If I packed WAR WebApp with more that one subclass of javax.ws.rs.Application, deployment fails with "JBAS011232: Only one JAX-RS Application Class allowed."
> This is not correct because it is against JAX-RS 1.1. specs where invalid situation (in section 2.3.2) is only when "It is a n error for
> more than one application to be deployed +at the same effective servlet mapping+".
> If you have any objections, please compare to reference JEE6 and JAX-RS implementation represented by the GlassFish Prelude 3.1.1 application server with already +fully JEE6 platform support+.
--
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
12 years, 5 months
[JBoss JIRA] (AS7-3197) username-attribute may not be null in ldap security realm
by Yves Peter (Created) (JIRA)
username-attribute may not be null in ldap security realm
---------------------------------------------------------
Key: AS7-3197
URL: https://issues.jboss.org/browse/AS7-3197
Project: Application Server 7
Issue Type: Bug
Reporter: Yves Peter
I tried the new JBoss 7.1 CR1 and get a strange error with this configuration that used to work in Beta1b:
<management>
<security-realms>
<security-realm name="PropertiesMgmtSecurityRealm">
<authentication>
<properties path="mgmt-users.properties" relative-to="jboss.server.config.dir" />
</authentication>
</security-realm>
<security-realm name="LDAPMgmtSecurityRealm">
<authentication>
<ldap connection="ldap_connection" recursive="true" base-dn="OU=yellow-Acc,DC=uyellow,DC=yellowcorp,DC=test">
<advanced-filter filter="(&(sAMAccountName={0})(memberOf=CN=AJBOSSSUPER,OU=Groups,OU=yellow-Acc,DC=uyellow,DC=yellowcorp,DC=test))" />
</ldap>
</authentication>
</security-realm>
</security-realms>
<outbound-connections>
<ldap name="ldap_connection" url=//addc01.uyellow.yellowcorp.test" search-dn="CN=User,OU=Service-Accounts,OU=yellow-Acc,DC=uyellow,DC=yellowcorp,DC=test"
search-credential="pw" />
</outbound-connections>
<management-interfaces>
<native-interface security-realm="PropertiesMgmtSecurityRealm">
<socket-binding native="management-native" />
</native-interface>
<http-interface security-realm="LDAPMgmtSecurityRealm">
<socket-binding http="management-http" />
</http-interface>
</management-interfaces>
</management>
Error:
16:26:24,923 INFO [org.jboss.modules] JBoss Modules version 1.1.0.CR6
16:26:25,635 INFO [org.jboss.msc] JBoss MSC version 1.0.1.GA
16:26:25,719 INFO [org.jboss.as] JBoss AS 7.1.0.CR1b "Flux Capacitor" starting
16:26:27,402 ERROR [org.jboss.as.controller.management-operation] Operation ("add") failed - address: ([
("core-service" => "management"),
("security-realm" => "LDAPMgmtSecurityRealm"),
("authentication" => "ldap")
]) - failure description: "JBAS014746: username-attribute may not be null"
16:26:27,407 INFO [org.jboss.as] JBoss AS 7.1.0.CR1b "Flux Capacitor" started in 2859ms - Started 19 of 20 services (1 services are passive or on-demand)
16:29:42,092 INFO [org.jboss.as] JBoss AS 7.1.0.CR1b "Flux Capacitor" stopped in 9ms
It used to work in the 7.1 Beta. I validated my xml and it seams to be valid.
--
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
12 years, 5 months