[JBoss JIRA] (WFLY-1099) Management Port sharing port 8080
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1099?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-1099:
------------------------------------
Assignee: (was: Stuart Douglas)
> Management Port sharing port 8080
> ---------------------------------
>
> Key: WFLY-1099
> URL: https://issues.jboss.org/browse/WFLY-1099
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Jim Tyrrell
> Labels: eap6-ux
>
> While it is great and there are many good reason to have a management console on a different port then the standard 8080 web ports, it should be possible to use port 8080 or equivalent for a management console and another port needing to be open should not be required, but can be a selectable feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-1030) Add Support for Equinox ForkJoinPool
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-1030?page=com.atlassian.jira.plugin.... ]
David Lloyd updated WFLY-1030:
------------------------------
Assignee: Eduardo Martins (was: David Lloyd)
> Add Support for Equinox ForkJoinPool
> ------------------------------------
>
> Key: WFLY-1030
> URL: https://issues.jboss.org/browse/WFLY-1030
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: EE
> Reporter: Philippe Marschall
> Assignee: Eduardo Martins
>
> Unfortunately JSR-236 does not address Java 7 fork/join pools. This puts people how want to use fork/join pools in an awkward position, either don't use them and wait for EE 8 (four or five years) or violate the "contract" and just create them anyway.
> This presents a great opportunity for AS8 to go further than the spec and provide a {{java.util.concurrent.ForkJoinPool}} and a {{java.util.concurrent.ForkJoinPool.ForkJoinWorkerThreadFactory}}. This allows us to innovate and standardize at a later time in EE 8 once we gained experience.
> This should include the following features:
> * Allow the configuration of {{java.util.concurrent.ForkJoinPool}} in the server configuration. You should be able to configure the parallelism and asyncMode (see constructor arguments). Similar to {{javax.enterprise.concurrent.ManagedExecutorService}}.
> * Allow the injection of {{java.util.concurrent.ForkJoinPool}} configured in the server. Similar to {{javax.enterprise.concurrent.ManagedExecutorService}}.
> * Allow the configuration of {{java.util.concurrent.ForkJoinPool.ForkJoinWorkerThreadFactory}} in the server configuration, merely to match the same feature in JSR-268.
> * Allow the injection of {{java.util.concurrent.ForkJoinPool.ForkJoinWorkerThreadFactory}} configured in the server (similar to Infinispan), merely to match the same feature in JSR-268.
> * {{java.util.concurrent.ForkJoinPool}} should per default not preserve the context http://java.net/projects/concurrency-ee-spec/lists/jsr236-experts/archive... (naming, security, transactions, class loading). Optionally you should be able to configure which contexts are preserved, this might be tough as {{ForkJoinPool}} is not designed for extensibility.
> I'm well aware that this is unspecified behaviour but so is Infinispan in AS7 and AS8 since JSR-107 again didn't make it.
> This issue is intended for AS8, not AS7.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-3275) Make log4j test scoped dependency
by James Perkins (JIRA)
James Perkins created WFLY-3275:
-----------------------------------
Summary: Make log4j test scoped dependency
Key: WFLY-3275
URL: https://issues.jboss.org/browse/WFLY-3275
Project: WildFly
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Logging
Reporter: James Perkins
Assignee: James Perkins
Priority: Minor
Fix For: 8.1.0.Final, 9.0.0.CR1
There's no real need for a log4j dependency except for some tests. Currently the log4j module is aliased to {{org.jboss.log4j.logmanager}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-956) deploy hangs if module import doesn't exist
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-956?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on WFLY-956:
----------------------------------
I think this points to a possibly fundamental problem with how we are handling module dependencies. I suspect that despite the recent dependency processing algorithm rework, mixing module loader types is still not quite right.
Ideally we'd have one uniform mechanism which sets up service dependencies for ServiceModuleLoader modules, and then uses static deps for static modules, which should allow everything to fail-fast (either with a service dependency error or a module dependency error depending on what kind of module is missing).
It might be even simpler/clearer if there were separate module loaders for extensions, file class path items, and deployment items. But that's not essential to solve this issue I don't think.
> deploy hangs if module import doesn't exist
> -------------------------------------------
>
> Key: WFLY-956
> URL: https://issues.jboss.org/browse/WFLY-956
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Class Loading
> Reporter: Bill Burke
> Assignee: David Lloyd
>
> If you have a module dependency and that module has its own dependency that doesn't exist, deployment will hang.
> To reproduce, create a simple WAR that has a jboss-deployment-structure.xml that imports an existing module. Have that existing module import a different module that doesn't exist.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-921) Context initialization exceptions are swallowed on deployment
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-921?page=com.atlassian.jira.plugin.s... ]
David Lloyd resolved WFLY-921.
------------------------------
Resolution: Out of Date
This code no longer exists in WildFly. If a similar problem occurs under WildFly please open a new issue with the "Undertow" subsystem.
> Context initialization exceptions are swallowed on deployment
> -------------------------------------------------------------
>
> Key: WFLY-921
> URL: https://issues.jboss.org/browse/WFLY-921
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE
> Environment: Windows 7
> Reporter: Jarkko Rantavuori
> Assignee: David Lloyd
> Attachments: jboss-7.1.1.-stacktrace-beans.txt, jboss-7.1.1.-stacktrace-namespace.txt, jboss-7.2.0.-stacktrace-namespace.txt, spring-app-1.0.0-BUILD-SNAPSHOT-startupexception.war
>
>
> On 7.2.0.Alpha1, trying to deploy a simple spring app with problems in context initialization, all exceptions are swallowed, and only a meaningless error
> org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161)
> is shown, making it impossible to find out the root cause.
> On 7.1.1., meaningful exception is shown, like
> Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.osgi.org/xmlns/blueprint/v1.0.0]
> Offending resource: ServletContext resource [/WEB-INF/spring/root-context.xml]
> or
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException
> Caused by: org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 108; cvc-elt.1: Cannot find the declaration of element 'beans'.
> which allows the developer to fix the problem.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-803) "NullPointerException" in RemotingConnectionEJBReceiver constructor if misconfigured
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-803?page=com.atlassian.jira.plugin.s... ]
David Lloyd updated WFLY-803:
-----------------------------
Description:
While experimenting with EJB remote access, I got confused with the proper configuration ;-). This resulted in a NullPointerException in one of your EJB client classes, and I think this should be handled by a meaningful error message.
I performed a lookup for "ejb:Stateless/StatelessEJB//GeometricModelBean!de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelRemote" => this means I want to use the JNDI lookup.
But in "jndi.properties", I used this: "jboss.naming.client.ejb.context=true" => This should probably activate "jboss-remote naming", and the lookup should be done for "Stateless/StatelessEJB//GeometricModelBean...". (no "ejb:" prefix).
Instead of an error message, this resulted in this console output, followed by an exception:
{noformat}
Feb 05, 2013 10:43:57 PM org.xnio.Xnio <clinit>
INFO: XNIO Version 3.0.7.GA
Feb 05, 2013 10:43:57 PM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.0.7.GA
Feb 05, 2013 10:43:57 PM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 3.2.14.GA
Feb 05, 2013 10:43:58 PM org.jboss.ejb.client.remoting.VersionReceiver handleMessage
INFO: EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
Feb 05, 2013 10:43:58 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate
INFO: EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@28ad5a, receiver=Remoting connection EJB receiver [connection=Remoting connection <c751fd>,channel=jboss.ejb,nodename=turbotante]} on channel Channel ID b93e696f (outbound) of Remoting connection 00411379 to localhost/127.0.0.1:4447
Feb 05, 2013 10:44:03 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate
INFO: EJBCLIENT000015: Initial module availability report for Remoting connection EJB receiver [connection=Remoting connection <c751fd>,channel=jboss.ejb,nodename=turbotante] wasn't received during the receiver context association
Feb 05, 2013 10:44:03 PM org.jboss.ejb.client.EJBClient <clinit>
INFO: JBoss EJB Client version 1.0.16.Final
java.lang.NullPointerException
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:102)
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:90)
at org.jboss.ejb.client.EJBClientContext.registerConnection(EJBClientContext.java:420)
at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getContext(RemoteNamingEjbClientContextSelector.java:60)
at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getCurrent(RemoteNamingEjbClientContextSelector.java:46)
at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getCurrent(RemoteNamingEjbClientContextSelector.java:15)
at org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271)
at org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:156)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:124)
at sun.proxy.$Proxy0.computeCuboidVolume(Unknown Source)
at de.fhw.komponentenarchitekturen.knauf.stateless.standaloneclient.GeometricModelApplicationClient.main(GeometricModelApplicationClient.java:38)
{noformat}
I will attach a sample. This is an Eclipse project. But i can also be run standalone: just modify "StatelessStandaloneClient\startclient.bat" to match your path to "jboss-client.jar" and start it (you need Java 1.7 for this). You don't even have to deploy the EAR app on the server to see the error. But if you want to do so: it is also part of the attachment: "Stateless.ear".
was:
While experimenting with EJB remote access, I got confused with the proper configuration ;-). This resulted in a NullPointerException in one of your EJB client classes, and I think this should be handled by a meaningful error message.
I performed a lookup for "ejb:Stateless/StatelessEJB//GeometricModelBean!de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelRemote" => this means I want to use the JNDI lookup.
But in "jndi.properties", I used this: "jboss.naming.client.ejb.context=true" => This should probably activate "jboss-remote naming", and the lookup should be done for "Stateless/StatelessEJB//GeometricModelBean...". (no "ejb:" prefix).
Instead of an error message, this resulted in this console output, followed by an exception:
Feb 05, 2013 10:43:57 PM org.xnio.Xnio <clinit>
INFO: XNIO Version 3.0.7.GA
Feb 05, 2013 10:43:57 PM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.0.7.GA
Feb 05, 2013 10:43:57 PM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 3.2.14.GA
Feb 05, 2013 10:43:58 PM org.jboss.ejb.client.remoting.VersionReceiver handleMessage
INFO: EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
Feb 05, 2013 10:43:58 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate
INFO: EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@28ad5a, receiver=Remoting connection EJB receiver [connection=Remoting connection <c751fd>,channel=jboss.ejb,nodename=turbotante]} on channel Channel ID b93e696f (outbound) of Remoting connection 00411379 to localhost/127.0.0.1:4447
Feb 05, 2013 10:44:03 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate
INFO: EJBCLIENT000015: Initial module availability report for Remoting connection EJB receiver [connection=Remoting connection <c751fd>,channel=jboss.ejb,nodename=turbotante] wasn't received during the receiver context association
Feb 05, 2013 10:44:03 PM org.jboss.ejb.client.EJBClient <clinit>
INFO: JBoss EJB Client version 1.0.16.Final
java.lang.NullPointerException
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:102)
at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:90)
at org.jboss.ejb.client.EJBClientContext.registerConnection(EJBClientContext.java:420)
at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getContext(RemoteNamingEjbClientContextSelector.java:60)
at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getCurrent(RemoteNamingEjbClientContextSelector.java:46)
at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getCurrent(RemoteNamingEjbClientContextSelector.java:15)
at org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271)
at org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:156)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:124)
at sun.proxy.$Proxy0.computeCuboidVolume(Unknown Source)
at de.fhw.komponentenarchitekturen.knauf.stateless.standaloneclient.GeometricModelApplicationClient.main(GeometricModelApplicationClient.java:38)
I will attach a sample. This is an Eclipse project. But i can also be run standalone: just modify "StatelessStandaloneClient\startclient.bat" to match your path to "jboss-client.jar" and start it (you need Java 1.7 for this). You don't even have to deploy the EAR app on the server to see the error. But if you want to do so: it is also part of the attachment: "Stateless.ear".
> "NullPointerException" in RemotingConnectionEJBReceiver constructor if misconfigured
> ------------------------------------------------------------------------------------
>
> Key: WFLY-803
> URL: https://issues.jboss.org/browse/WFLY-803
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Environment: Tested with 7.2.0 Alpha snapshot of 2013-02-05
> Sample project is build with Java 1.7
> Reporter: Wolfgang Knauf
> Assignee: David Lloyd
> Priority: Minor
> Attachments: StatelessStandaloneClient.zip
>
>
> While experimenting with EJB remote access, I got confused with the proper configuration ;-). This resulted in a NullPointerException in one of your EJB client classes, and I think this should be handled by a meaningful error message.
> I performed a lookup for "ejb:Stateless/StatelessEJB//GeometricModelBean!de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelRemote" => this means I want to use the JNDI lookup.
> But in "jndi.properties", I used this: "jboss.naming.client.ejb.context=true" => This should probably activate "jboss-remote naming", and the lookup should be done for "Stateless/StatelessEJB//GeometricModelBean...". (no "ejb:" prefix).
> Instead of an error message, this resulted in this console output, followed by an exception:
> {noformat}
> Feb 05, 2013 10:43:57 PM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.7.GA
> Feb 05, 2013 10:43:57 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.7.GA
> Feb 05, 2013 10:43:57 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.14.GA
> Feb 05, 2013 10:43:58 PM org.jboss.ejb.client.remoting.VersionReceiver handleMessage
> INFO: EJBCLIENT000017: Received server version 1 and marshalling strategies [river]
> Feb 05, 2013 10:43:58 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate
> INFO: EJBCLIENT000013: Successful version handshake completed for receiver context EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@28ad5a, receiver=Remoting connection EJB receiver [connection=Remoting connection <c751fd>,channel=jboss.ejb,nodename=turbotante]} on channel Channel ID b93e696f (outbound) of Remoting connection 00411379 to localhost/127.0.0.1:4447
> Feb 05, 2013 10:44:03 PM org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver associate
> INFO: EJBCLIENT000015: Initial module availability report for Remoting connection EJB receiver [connection=Remoting connection <c751fd>,channel=jboss.ejb,nodename=turbotante] wasn't received during the receiver context association
> Feb 05, 2013 10:44:03 PM org.jboss.ejb.client.EJBClient <clinit>
> INFO: JBoss EJB Client version 1.0.16.Final
> java.lang.NullPointerException
> at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:102)
> at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.<init>(RemotingConnectionEJBReceiver.java:90)
> at org.jboss.ejb.client.EJBClientContext.registerConnection(EJBClientContext.java:420)
> at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getContext(RemoteNamingEjbClientContextSelector.java:60)
> at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getCurrent(RemoteNamingEjbClientContextSelector.java:46)
> at org.jboss.naming.remote.client.ejb.RemoteNamingEjbClientContextSelector.getCurrent(RemoteNamingEjbClientContextSelector.java:15)
> at org.jboss.ejb.client.EJBClientContext.getCurrent(EJBClientContext.java:271)
> at org.jboss.ejb.client.EJBClientContext.requireCurrent(EJBClientContext.java:281)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:156)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:124)
> at sun.proxy.$Proxy0.computeCuboidVolume(Unknown Source)
> at de.fhw.komponentenarchitekturen.knauf.stateless.standaloneclient.GeometricModelApplicationClient.main(GeometricModelApplicationClient.java:38)
> {noformat}
> I will attach a sample. This is an Eclipse project. But i can also be run standalone: just modify "StatelessStandaloneClient\startclient.bat" to match your path to "jboss-client.jar" and start it (you need Java 1.7 for this). You don't even have to deploy the EAR app on the server to see the error. But if you want to do so: it is also part of the attachment: "Stateless.ear".
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (WFLY-832) module.xml schema checking should log errors when it encounters them
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-832?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on WFLY-832:
----------------------------------
Testing with a simple case, I got this error:
{noformat}
Exception in thread "main" org.jboss.modules.ModuleLoadException: Error loading module from /home/david/src/java/wildfly/build/target/wildfly-8.0.1.Final-SNAPSHOT/modules/system/layers/base/org/jboss/as/standalone/main/module.xml
at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:155)
at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:132)
at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:154)
at org.jboss.modules.LocalModuleFinder$1.run(LocalModuleFinder.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.modules.LocalModuleFinder.findModule(LocalModuleFinder.java:148)
at org.jboss.modules.ModuleLoader.findModule(ModuleLoader.java:455)
at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:358)
at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:305)
at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:238)
at org.jboss.modules.Main.main(Main.java:385)
Caused by: org.jboss.modules.xml.XmlPullParserException: end tag name </resouruces> must match start tag name <resources> from line 32 (position: TEXT seen ...<resources>\n </resouruces>... @33:18)
at org.jboss.modules.xml.MXParser.parseEndTag(MXParser.java:1686)
at org.jboss.modules.xml.MXParser.nextImpl(MXParser.java:1128)
at org.jboss.modules.xml.MXParser.next(MXParser.java:1090)
at org.jboss.modules.xml.MXParser.nextTag(MXParser.java:1077)
at org.jboss.modules.ModuleXmlParser.parseResources(ModuleXmlParser.java:563)
at org.jboss.modules.ModuleXmlParser.parseModuleContents(ModuleXmlParser.java:394)
at org.jboss.modules.ModuleXmlParser.parseDocument(ModuleXmlParser.java:219)
at org.jboss.modules.ModuleXmlParser.parseModuleXml(ModuleXmlParser.java:153)
... 10 more
{noformat}
I think perhaps the newer pull parser might be more strict about this. If JDBC driver errors however are still not being logged, then it might be a bug in the driver loading code, where it doesn't log exceptions properly.
> module.xml schema checking should log errors when it encounters them
> ---------------------------------------------------------------------
>
> Key: WFLY-832
> URL: https://issues.jboss.org/browse/WFLY-832
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Reporter: Tom Fonteyne
> Assignee: David Lloyd
> Priority: Minor
>
> When defining a JDBC driver, we made a syntax error in the module.xml
> <resources>
> <resource-root path="driver.jar"/>
> </resoruces>
> Note the misspelled closing tag "</resoruces>"
> The driver did not get loaded (logically) but no error message was logged in server.log about this
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months