[JBoss JIRA] (WFLY-943) XML schema; use of elementFormDefault='unqualified'; cannot validate some documents
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-943?page=com.atlassian.jira.plugin.s... ]
Radoslav Husar updated WFLY-943:
--------------------------------
Comment: was deleted
(was: Dear sir, madam,
Thank you, your e-mail has arrived. Unfortunately I am not available to answer your message at the moment. I am out of office, starting from 20-12-2013.
As of 02-01-2014, I will be able to answer your e-mail again.
Met vriendelijke groet/
Kind regards,
ing. Jan-Willem Mulder Head of Back End Development
E: jan-willem.mulder(a)isaac.nl<mailto:jan-willem.mulder@isaac.nl>
T: 040 215 53 58 - M: 06 11 34 81 48 - F: 040 290 89 80 - W: http://www.isaac.nl/
Marconilaan 16, 5621 AA Eindhoven - The Netherlands
Dit e-mailbericht is alleen bestemd voor de geadresseerde(n). Indien dit bericht niet voor u is bedoeld wordt u verzocht de afzender hiervan
op de hoogte te stellen door het bericht te retourneren en de inhoud niet te gebruiken. Aan dit bericht kunnen geen rechten worden ontleend.
)
> XML schema; use of elementFormDefault='unqualified'; cannot validate some documents
> -----------------------------------------------------------------------------------
>
> Key: WFLY-943
> URL: https://issues.jboss.org/browse/WFLY-943
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Documentation
> Affects Versions: 8.0.0.Alpha3
> Reporter: Elias Ross
> Fix For: 8.0.0.Final
>
> Attachments: jboss-deployment-structure.xml
>
>
> When attempting to write a (seemingly) valid jboss-deployment-structure.xml using the schema in ./docs, my document fails to validate.
> This is because of the settings used in the XSD. Have these XSDs been used to validate actual documents? By setting unqualified to 'qualified' then the documents will probably validate.
> $ git grep elementFormDefault..unqualified
> jboss-deployment-dependencies-1_0.xsd: elementFormDefault="unqualified"
> jboss-deployment-structure-1_0.xsd: elementFormDefault="unqualified"
> jboss-deployment-structure-1_1.xsd: elementFormDefault="unqualified"
> jboss-deployment-structure-1_2.xsd: elementFormDefault="unqualified"
> jboss-ejb-client_1_0.xsd: elementFormDefault="unqualified"
> jboss-ejb-client_1_1.xsd: elementFormDefault="unqualified"
> jboss-ejb-client_1_2.xsd: elementFormDefault="unqualified"
> jboss-jpa_1_0.xsd: elementFormDefault="unqualified"
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-1376) HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
by nathan dennis (JIRA)
[ https://issues.jboss.org/browse/WFLY-1376?page=com.atlassian.jira.plugin.... ]
nathan dennis commented on WFLY-1376:
-------------------------------------
Actual I believe the bug which I was seeing was WFLY-2688. It has also been fixed in trunk.
> HttpServletResponseImpl.getWriter() cannot be called: getOutputStream() already called
> --------------------------------------------------------------------------------------
>
> Key: WFLY-1376
> URL: https://issues.jboss.org/browse/WFLY-1376
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> When I invoke a RESTful web service for a not existing URI (resulting in a 404 error) I'm getting the stacktrace below. This is working fine with EAP 6.1.Beta.
> In web.xml I have this declaration for a 404 error and a JSF-based error page:
> <error-page>
> <error-code>404</error-code>
> <location>/error/pageNotFound.jsf</location>
> </error-page>
> Stacktrace:
> 12:36:03,921 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] Error Rendering View[/error/pageNotFound.xhtml]: java.lang.IllegalStateException: UT010006: Cannot call getWriter(), getOutputStream() already called
> at io.undertow.servlet.spec.HttpServletResponseImpl.getWriter(HttpServletResponseImpl.java:284) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at com.sun.faces.context.ExternalContextImpl.getResponseOutputWriter(ExternalContextImpl.java:834) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.context.ExternalContextWrapper.getResponseOutputWriter(ExternalContextWrapper.java:785) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.createResponseWriter(FaceletViewHandlingStrategy.java:1166) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:390) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:337) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219) [jsf-impl-2.2.0-m13-jbossorg-1.jar:]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647) [jboss-jsf-api_2.2_spec-2.2.0-m13.jar:2.2.0-m13]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:87) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:54) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:116) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:79)
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeHandler(HttpHandlers.java:46) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:26) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:108) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchToPath(ServletInitialHandler.java:93) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:367) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.RequestDispatcherImpl.error(RequestDispatcherImpl.java:286) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:124) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:106) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleRequest(ServletInitialHandler.java:83) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpHandlers.executeRootHandler(HttpHandlers.java:52) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:544) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2856) Classloader leak caused by xnio-file-watcher
by Harald Wellmann (JIRA)
Harald Wellmann created WFLY-2856:
-------------------------------------
Summary: Classloader leak caused by xnio-file-watcher
Key: WFLY-2856
URL: https://issues.jboss.org/browse/WFLY-2856
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 8.0.0.CR1
Reporter: Harald Wellmann
After redeploying my application from Eclipe/JBoss Tools via "Full Publish" a couple of times in a row, I'm getting a PermGen OutOfMemoryError.
In jvisualvm, I can see multiple threads named xnio-file-watcher, each having its context classloader set to the module classloader of my (undeployed) application. Probably the thread should be stopped (but isn't) when the application is undeployed.
This leak only occurs with unzipped deployments.
I also see these extra threads independent of Eclipse when copying an unzipped deployment to {{standalone/deployments}} and adding/removing the dodeploy/deployed marker files.
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-2611) Unify JSF action listener and CDI integration
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-2611?page=com.atlassian.jira.plugin.... ]
Tomas Remes updated WFLY-2611:
------------------------------
Description:
There are three ways, how can user specify custom JSF action listener:
1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class.
3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed.
Reproducer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/actionlist.... Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
was:
There are three ways, how can user specify custom JSF action listener:
1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class.
3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed.
Reproducer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/jsf-listen.... Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
> Unify JSF action listener and CDI integration
> ---------------------------------------------
>
> Key: WFLY-2611
> URL: https://issues.jboss.org/browse/WFLY-2611
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Affects Versions: 8.0.0.CR1
> Reporter: Tomas Remes
> Assignee: Farah Juma
>
> There are three ways, how can user specify custom JSF action listener:
> 1. Method binding - with actionListener param. This case is ok, meaning CDI injection and interceptor works for given method/bean.
> 2. Providing custom implementation - <f:actionListener type="org.jboss.jsf.listeners.MyActionListener"/>. In this case CDI doesn't work at all for processAction method of given class.
> 3. Defining in faces-config - in this case CDI injection works, but interceptor is not executed.
> Reproducer available at https://github.com/tremes/javaee7-samples/tree/cdi-testing/jsf/actionlist.... Test can be executed with "mvn clean test -Pwildfly-managed-arquillian" or "mvn clean test -Pwildfly-remote-arquillian" and IMHO all should pass.
>
--
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
12 years, 3 months
[JBoss JIRA] (WFLY-1380) Undertow: Error initialize the net.jawr.web.servlet.JawrServlet with undertow
by Laszlo Varga (JIRA)
[ https://issues.jboss.org/browse/WFLY-1380?page=com.atlassian.jira.plugin.... ]
Laszlo Varga commented on WFLY-1380:
------------------------------------
I have the same error message, but not with Liferay.
Do you use drw spring integration? In case yes, this might cause the problem.
> Undertow: Error initialize the net.jawr.web.servlet.JawrServlet with undertow
> -----------------------------------------------------------------------------
>
> Key: WFLY-1380
> URL: https://issues.jboss.org/browse/WFLY-1380
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Igor Shulika
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> I'm deploying a OSGi WAB file on the latest WildFly 8.0.0.Alpha2-SNAPSHOT server. Can not initialize the JavascriptServlet from JAWR Bundle. Note: When I used the <extension module="org.jboss.as.web"/> insted of <extension module="org.wildfly.extension.undertow"/> it works.
> Please see error trace below.
> Thanks!
> 12:20:41,629 FATAL [net.jawr.web.servlet.JawrServlet] (MSC service thread 1-7) Jawr servlet with name JavascriptServlet failed to initialize properly.
> 12:20:41,629 FATAL [net.jawr.web.servlet.JawrServlet] (MSC service thread 1-7) Cause:
> 12:20:41,629 FATAL [net.jawr.web.servlet.JawrServlet] (MSC service thread 1-7) Illegal char <:> at index 3: dwr:WebServiceDocService: java.nio.file.InvalidPathException: Illegal char <:> at index 3: dwr:WebServiceDocService
> at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) [rt.jar:1.7.0_21]
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153) [rt.jar:1.7.0_21]
> at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77) [rt.jar:1.7.0_21]
> at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94) [rt.jar:1.7.0_21]
> at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255) [rt.jar:1.7.0_21]
> at sun.nio.fs.AbstractPath.resolve(AbstractPath.java:53) [rt.jar:1.7.0_21]
> at io.undertow.server.handlers.resource.FileResourceManager.getResource(FileResourceManager.java:57) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.server.handlers.resource.CachingResourceManager.getResource(CachingResourceManager.java:68) [undertow-core-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.spec.ServletContextImpl.getResourceAsStream(ServletContextImpl.java:175) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at net.jawr.web.resource.handler.reader.ServletContextResourceReader.getResource(ServletContextResourceReader.java:70) [ServletContextResourceReader.class:]
> at net.jawr.web.resource.handler.reader.ServletContextResourceReaderHandler.getResource(ServletContextResourceReaderHandler.java:192) [ServletContextResourceReaderHandler.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.joinAndPostprocessBundle(ResourceBundlesHandlerImpl.java:892) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.joinAndPostProcessBundle(ResourceBundlesHandlerImpl.java:835) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.joinAndStoreBundle(ResourceBundlesHandlerImpl.java:766) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.ResourceBundlesHandlerImpl.initAllBundles(ResourceBundlesHandlerImpl.java:542) [ResourceBundlesHandlerImpl.class:]
> at net.jawr.web.resource.bundle.handler.CachedResourceBundlesHandler.initAllBundles(CachedResourceBundlesHandler.java:126) [CachedResourceBundlesHandler.class:]
> at net.jawr.web.resource.bundle.factory.BundlesHandlerFactory.buildResourceBundlesHandler(BundlesHandlerFactory.java:233) [BundlesHandlerFactory.class:]
> at net.jawr.web.resource.bundle.factory.PropertiesBasedBundlesHandlerFactory.buildResourceBundlesHandler(PropertiesBasedBundlesHandlerFactory.java:204) [PropertiesBasedBundlesHandlerFactory.class:]
> at net.jawr.web.servlet.JawrRequestHandler.initializeJawrConfig(JawrRequestHandler.java:349) [JawrRequestHandler.class:]
> at net.jawr.web.servlet.JawrRequestHandler.initRequestHandler(JawrRequestHandler.java:262) [JawrRequestHandler.class:]
> at net.jawr.web.servlet.JawrRequestHandler.<init>(JawrRequestHandler.java:184) [JawrRequestHandler.class:]
> at net.jawr.web.servlet.JawrServlet.init(JawrServlet.java:56) [JawrServlet.class:]
> at javax.servlet.GenericServlet.init(GenericServlet.java:244) [jboss-servlet-api_3.1_spec-1.0.0.Alpha1.jar:1.0.0.Alpha1]
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:145) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.core.ManagedServlet.start(ManagedServlet.java:62) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:599) [undertow-servlet-1.0.0.Alpha15.jar:1.0.0.Alpha15]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:77)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1974) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1907) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
--
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
12 years, 3 months