February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-556) Remove usage of jboss-common-core in domain-managment

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-556?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-556: ------------------------------------ Fix Version/s: 2.0.0.Alpha1 > Remove usage of jboss-common-core in domain-managment > ----------------------------------------------------- > > Key: WFCORE-556 > URL: https://issues.jboss.org/browse/WFCORE-556 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Tomaz Cerar > Assignee: Brian Stansberry > Fix For: 2.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4372) "jboss-deployment-structure.xml" with schema location fails to deploy

by Wolfgang Knauf (JIRA)

Wolfgang Knauf created WFLY-4372: ------------------------------------ Summary: "jboss-deployment-structure.xml" with schema location fails to deploy Key: WFLY-4372 URL: https://issues.jboss.org/browse/WFLY-4372 Project: WildFly Issue Type: Bug Components: Server Affects Versions: 8.2.0.Final Reporter: Wolfgang Knauf Assignee: Jason Greene Priority: Minor A "jboss-deployment-structure.xml" with a schemaLocation attribute will fail to deploy. This is a sample file: <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:jboss:deployment-structure:1.1 http://www.jboss.org/schema/jbossas/jboss-deployment-structure-1_1.xsd"> ... </jboss-deployment-structure> And this is the deployment error: And this is the parse exception: Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,129] Message: JBAS018754: Unexpected content of type 'element start', name is '{urn:jboss:deployment-structure:1.1}jboss-deployment-structure', text is: 'null' at org.jboss.as.server.deployment.module.descriptor.JBossDeploymentStructureParser11.unexpectedContent(JBossDeploymentStructureParser11.java:1129) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.server.deployment.module.descriptor.JBossDeploymentStructureParser11.readElement(JBossDeploymentStructureParser11.java:211) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.as.server.deployment.module.descriptor.JBossDeploymentStructureParser11.readElement(JBossDeploymentStructureParser11.java:69) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) at org.jboss.as.server.deployment.module.descriptor.DeploymentStructureDescriptorParser.parse(DeploymentStructureDescriptorParser.java:316) [wildfly-server-8.2.0.Final.jar:8.2.0.Final] ... 8 more The schemaLocation attribute makes sense, because Eclipse will be able to validate the file,and you have code completion. With the JBossTools plugin, the "xmlns" attribute is enough to get all this, because JBossTools adds this file to the xml catalog. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4362) Web container (undertow) isn't able to compile JSPs containing JDK 8 specific code (lambda expressions)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4362?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4362: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1193553, https://bugzilla.redhat.com/show_bug.cgi?id=1194436 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1193553) > Web container (undertow) isn't able to compile JSPs containing JDK 8 specific code (lambda expressions) > ------------------------------------------------------------------------------------------------------- > > Key: WFLY-4362 > URL: https://issues.jboss.org/browse/WFLY-4362 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 9.0.0.Alpha1 > Environment: jdk1.8 > Reporter: Radim Hatlapatka > Assignee: Tomaz Cerar > Priority: Critical > Attachments: lambda-expression-test.war > > > Accessing JSP with JDK8 specific code (namely lambda expressions) fails due compilation error [1]. > It didn't help setting > {code} > <jsp-config source-vm="1.8" target-vm="1.8"/> in <servlet-container name="default"> > {code} > It is caused due ecj-4.3.1.jar supports only JDKs till 1.7. > [1] > {noformat} > 09:58:44,480 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /lambda-expression-test/jsp-with-lambdas.jsp: org.apache.jasper.JasperException: JBWEB004062: Unable to compile class for JSP: > JBWEB004060: An error occurred at line: 10 in the jsp file: /jsp-with-lambdas.jsp > n cannot be resolved to a variable > 7: // System.out.println(answerToEverything); > 8: > 9: List<Integer> list = Arrays.asList(1, 2, 3); > 10: Arrays.asList(1).forEach(n-> System.out.println(n)); > 11: > 12: list.forEach(n -> response.getWriter().write("" + n + "")); > 13: > JBWEB004060: An error occurred at line: 10 in the jsp file: /jsp-with-lambdas.jsp > Syntax error on token "-", -- expected > 7: // System.out.println(answerToEverything); > 8: > 9: List<Integer> list = Arrays.asList(1, 2, 3); > 10: Arrays.asList(1).forEach(n-> System.out.println(n)); > 11: > 12: list.forEach(n -> response.getWriter().write("" + n + "")); > 13: > JBWEB004060: An error occurred at line: 10 in the jsp file: /jsp-with-lambdas.jsp > n cannot be resolved to a variable > 7: // System.out.println(answerToEverything); > 8: > 9: List<Integer> list = Arrays.asList(1, 2, 3); > 10: Arrays.asList(1).forEach(n-> System.out.println(n)); > 11: > 12: list.forEach(n -> response.getWriter().write("" + n + "")); > 13: > JBWEB004060: An error occurred at line: 12 in the jsp file: /jsp-with-lambdas.jsp > n cannot be resolved to a variable > 9: List<Integer> list = Arrays.asList(1, 2, 3); > 10: Arrays.asList(1).forEach(n-> System.out.println(n)); > 11: > 12: list.forEach(n -> response.getWriter().write("" + n + "")); > 13: > 14: %> > 15: </body> > JBWEB004060: An error occurred at line: 12 in the jsp file: /jsp-with-lambdas.jsp > Syntax error on token "-", -- expected > 9: List<Integer> list = Arrays.asList(1, 2, 3); > 10: Arrays.asList(1).forEach(n-> System.out.println(n)); > 11: > 12: list.forEach(n -> response.getWriter().write("" + n + "")); > 13: > 14: %> > 15: </body> > JBWEB004060: An error occurred at line: 12 in the jsp file: /jsp-with-lambdas.jsp > n cannot be resolved to a variable > 9: List<Integer> list = Arrays.asList(1, 2, 3); > 10: Arrays.asList(1).forEach(n-> System.out.println(n)); > 11: > 12: list.forEach(n -> response.getWriter().write("" + n + "")); > 13: > 14: %> > 15: </body> > JBWEB004211: Stacktrace: > at org.apache.jasper.compiler.DefaultErrorHandler.javacError(DefaultErrorHandler.java:85) [jastow-1.0.0.Final.jar:1.0.0.Final] > at org.apache.jasper.compiler.ErrorDispatcher.javacError(ErrorDispatcher.java:69) [jastow-1.0.0.Final.jar:1.0.0.Final] > at org.apache.jasper.compiler.JDTCompiler.generateClass(JDTCompiler.java:451) [jastow-1.0.0.Final.jar:1.0.0.Final] > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:361) [jastow-1.0.0.Final.jar:1.0.0.Final] > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:339) [jastow-1.0.0.Final.jar:1.0.0.Final] > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final] > at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:604) [jastow-1.0.0.Final.jar:1.0.0.Final] > at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:309) [jastow-1.0.0.Final.jar:1.0.0.Final] > at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:326) [jastow-1.0.0.Final.jar:1.0.0.Final] > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:259) [jastow-1.0.0.Final.jar:1.0.0.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final] > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:63) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:261) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:247) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:76) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:166) [undertow-servlet-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:759) [undertow-core-1.1.0.Final.jar:1.1.0.Final] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_75] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_75] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_75] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBASMP-71) JBoss Maven Plugin fails deploy in domain mode if one server is stopped

by Chris Dollar (JIRA)

[ https://issues.jboss.org/browse/JBASMP-71?page=com.atlassian.jira.plugin.... ] Chris Dollar commented on JBASMP-71: ------------------------------------ I'd like to add my vote to have this pull request merged in. I'm actually an EAP customer and I had logged a support request dealing with the plugin not allowing me to deploy. As it turns out the reason for the failure was not all the servers in my server group were started (and support pointed me to this pull request). In my particular use case our business traffic coincides with normal school years, so our peak traffic comes during the start of a new school semester. With our managed servers we start more instances during peak times to handle the load, and shut them down as our load decreases. This means that most of the time we have managed servers defined in our domain that are not started. Chris > JBoss Maven Plugin fails deploy in domain mode if one server is stopped > ----------------------------------------------------------------------- > > Key: JBASMP-71 > URL: https://issues.jboss.org/browse/JBASMP-71 > Project: JBoss AS Maven Plugins > Issue Type: Bug > Components: deploy > Affects Versions: 7.5.Final > Reporter: Jorge Solorzano > Assignee: James Perkins > > I have a cluster in domain mode and configured my project to do the deploy on a server group (jboss-as:deploy), but if I have one server stopped the deploy fails. > I think it should do the deploy even if all servers are stopped, after all the master is the one who get the deploy and when the servers come back online then the master sends the content to the servers. > If I do the deploy directly from the manangement console it don't care if all servers (in the server group) are stopped. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4369) Remove usage of jboss-common-core in connector

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-4369?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reopened WFLY-4369: ------------------------------- Assignee: Tomaz Cerar (was: Jesper Pedersen) It is used as dependency if noting else. https://github.com/wildfly/wildfly/blob/master/connector/pom.xml#L66-66 will remove it as part of the sweep. > Remove usage of jboss-common-core in connector > ---------------------------------------------- > > Key: WFLY-4369 > URL: https://issues.jboss.org/browse/WFLY-4369 > Project: WildFly > Issue Type: Sub-task > Components: JCA > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > jboss-common-core usage should be reviewed and if possible eliminated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/REMJMX-94?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated REMJMX-94: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1191002 > Memory leak in remoting-jmx > --------------------------- > > Key: REMJMX-94 > URL: https://issues.jboss.org/browse/REMJMX-94 > Project: Remoting JMX > Issue Type: Bug > Affects Versions: 1.1.3.Final > Reporter: Libor Zoubek > Assignee: Darran Lofthouse > Labels: memory_leak > > In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed. > I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps: > 1. start new thread > 2. assign URL classloader to this thread (point it to jboss-client.jar) > 3. connect & disconnect to jmx-remoting endpoint > In this test no classes don't get GCed which after serveral iterations ends up in OOM. > My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org... > I am not sure if memleak is in remoting-jmx or some other underlying stuff. > I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4369) Remove usage of jboss-common-core in connector

by Jesper Pedersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-4369?page=com.atlassian.jira.plugin.... ] Jesper Pedersen resolved WFLY-4369. ----------------------------------- Resolution: Done Not used > Remove usage of jboss-common-core in connector > ---------------------------------------------- > > Key: WFLY-4369 > URL: https://issues.jboss.org/browse/WFLY-4369 > Project: WildFly > Issue Type: Sub-task > Components: JCA > Reporter: Tomaz Cerar > Assignee: Jesper Pedersen > > jboss-common-core usage should be reviewed and if possible eliminated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4371) Remove usage of jboss-common-core in pojo subsystem

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-4371: --------------------------------- Summary: Remove usage of jboss-common-core in pojo subsystem Key: WFLY-4371 URL: https://issues.jboss.org/browse/WFLY-4371 Project: WildFly Issue Type: Sub-task Components: POJO Reporter: Tomaz Cerar Assignee: Ales Justin jboss-common-core usage should be reviewed and if possible eliminated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4370) Remove usage of jboss-common-core in jsr77

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-4370: --------------------------------- Summary: Remove usage of jboss-common-core in jsr77 Key: WFLY-4370 URL: https://issues.jboss.org/browse/WFLY-4370 Project: WildFly Issue Type: Sub-task Components: Domain Management Reporter: Tomaz Cerar Assignee: Brian Stansberry jboss-common-core usage should be reviewed and if possible eliminated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4369) Remove usage of jboss-common-core in connector

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFLY-4369: --------------------------------- Summary: Remove usage of jboss-common-core in connector Key: WFLY-4369 URL: https://issues.jboss.org/browse/WFLY-4369 Project: WildFly Issue Type: Sub-task Components: JCA Reporter: Tomaz Cerar Assignee: Jesper Pedersen jboss-common-core usage should be reviewed and if possible eliminated. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
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 February 2015