February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4367) jboss-cli.xml should include timeout of 30 seconds

by Travis Rogers (JIRA)

Travis Rogers created WFLY-4367: ----------------------------------- Summary: jboss-cli.xml should include timeout of 30 seconds Key: WFLY-4367 URL: https://issues.jboss.org/browse/WFLY-4367 Project: WildFly Issue Type: Bug Components: CLI Affects Versions: 8.2.0.Final Reporter: Travis Rogers Assignee: Alexey Loubyansky Description of problem: CLI commands use a default timeout of 5 seconds. Testing has shown that connection timeouts will occur with a timeout value this low. Recommended value is 30 seconds. The following default setting should be added to $JBOSS_HOME/bin/jboss-cli.xml: <connection-timeout>30000</connection-timeout> Version-Release number of selected component (if applicable): How to reproduce: Loop calling the CLI executing a command. Example command: jboss-cli.sh -c --command=":read-attribute(name=server-state)" Actual results: Connection timeout error will eventually be thrown. Expected results: No errors due to connection timeout. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4366) WebSocket Endpoint's onClose not always called on close

by Toby Crawley (JIRA)

Toby Crawley created WFLY-4366: ---------------------------------- Summary: WebSocket Endpoint's onClose not always called on close Key: WFLY-4366 URL: https://issues.jboss.org/browse/WFLY-4366 Project: WildFly Issue Type: Bug Components: Web Sockets Affects Versions: 9.0.0.Alpha1, 8.2.0.Final Reporter: Toby Crawley Assignee: Stuart Douglas When closing the browser, my Endpoint's onClose handler isn't always called. I can recreate this by connecting to the Endpoint in 3-4 browser tabs in a single window, then closing the window. I see onClose being triggered for 1-2 of the connections, but rarely for all. After the browser is closed, all of the Sessions that were created return false for isOpen. If I run a similar app in Undertow (1.1.0.Final) that uses a WebSocketChannel directly, I don't see this behavior - WebSocketChannel.onCloseMessage gets called for every connection, which leads me to believe the issue is somewhere in the jsr implementation. Let me know if you need any more details, or want me to test anything on my end. -- 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 Radim Hatlapatka (JIRA)

[ https://issues.jboss.org/browse/WFLY-4362?page=com.atlassian.jira.plugin.... ] Radim Hatlapatka updated WFLY-4362: ----------------------------------- Attachment: lambda-expression-test.war Thanks for noticing, updating the attachment with new JSP, which I have tried also with glassfish, this one should be ok. > 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] (WFLY-4362) Web container (undertow) isn't able to compile JSPs containing JDK 8 specific code (lambda expressions)

by Radim Hatlapatka (JIRA)

[ https://issues.jboss.org/browse/WFLY-4362?page=com.atlassian.jira.plugin.... ] Radim Hatlapatka updated WFLY-4362: ----------------------------------- Attachment: (was: lambda-expression-test.war) > 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 > > 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] (WFLY-4275) Implicit EE component attached to a root implicit bean archive recognized as implicit bean

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-4275?page=com.atlassian.jira.plugin.... ] Martin Kouba reassigned WFLY-4275: ---------------------------------- Assignee: Stuart Douglas (was: Martin Kouba) > Implicit EE component attached to a root implicit bean archive recognized as implicit bean > ------------------------------------------------------------------------------------------ > > Key: WFLY-4275 > URL: https://issues.jboss.org/browse/WFLY-4275 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld > Affects Versions: 9.0.0.Alpha1 > Reporter: Martin Kouba > Assignee: Stuart Douglas > > This is no longer necessary (see also WELD-1612). Furhtermore, it's producing confusing results. For example, an {{ProcessBeanAttributes}} event is fired for {{com.sun.faces.config.ConfigureListener}}, {{org.jboss.weld.servlet.WeldInitialListener}} and other implicitly added EE components for a WAR deployment with {{bean-discovery-mode="annotated"}}. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1424) Remote lookup for Referenceable returns Reference and not the real object

by Dominik Pospisil (JIRA)

[ https://issues.jboss.org/browse/WFLY-1424?page=com.atlassian.jira.plugin.... ] Dominik Pospisil commented on WFLY-1424: ---------------------------------------- Associated testcase: https://github.com/dpospisil/wildfly/commit/066a7fec5c50f9b0466abfd6a43bb... > Remote lookup for Referenceable returns Reference and not the real object > ------------------------------------------------------------------------- > > Key: WFLY-1424 > URL: https://issues.jboss.org/browse/WFLY-1424 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 8.0.0.Alpha1 > Reporter: Natasha Biryukov > Assignee: Dominik Pospisil > > In JBoss EAP6.1 Alfa and Beta during remote lookup for obejct that implements Referenceable the coresponding ObjectFactory is not called, as a result the Reference object is returned and not the real one. > Code example: > public class Fruit implements Referenceable { > String fruit; > public Fruit(String f) { > fruit = f; > } > public Reference getReference() throws NamingException { > return new Reference( > Fruit.class.getName(), > new StringRefAddr("fruit", fruit), > FruitFactory.class.getName(), > null); > } > public String toString() { > return fruit; > } > } > public class FruitFactory implements ObjectFactory { > @Override > public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment) throws Exception { > Reference localObject1; > if (obj instanceof Reference) { > localObject1 = (Reference) obj; > Object fruit = localObject1.get("fruit").getContent(); > return new Fruit((String)fruit); > } else { > return obj; > } > } > } > Fruit f = new Fruit("apple"); > context.bind("apple", f); > Fruit f1 = (Fruit)context.lookup("apple"); -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-1424) Remote lookup for Referenceable returns Reference and not the real object

by Dominik Pospisil (JIRA)

[ https://issues.jboss.org/browse/WFLY-1424?page=com.atlassian.jira.plugin.... ] Dominik Pospisil resolved WFLY-1424. ------------------------------------ Resolution: Out of Date I have tested this issue on current master (WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha18)) and the issue does not seem to be present. References stored in naming context are being dereferended by remote client as expected. > Remote lookup for Referenceable returns Reference and not the real object > ------------------------------------------------------------------------- > > Key: WFLY-1424 > URL: https://issues.jboss.org/browse/WFLY-1424 > Project: WildFly > Issue Type: Bug > Components: Naming > Affects Versions: 8.0.0.Alpha1 > Reporter: Natasha Biryukov > Assignee: Dominik Pospisil > > In JBoss EAP6.1 Alfa and Beta during remote lookup for obejct that implements Referenceable the coresponding ObjectFactory is not called, as a result the Reference object is returned and not the real one. > Code example: > public class Fruit implements Referenceable { > String fruit; > public Fruit(String f) { > fruit = f; > } > public Reference getReference() throws NamingException { > return new Reference( > Fruit.class.getName(), > new StringRefAddr("fruit", fruit), > FruitFactory.class.getName(), > null); > } > public String toString() { > return fruit; > } > } > public class FruitFactory implements ObjectFactory { > @Override > public Object getObjectInstance(Object obj, Name name, Context nameCtx, Hashtable<?, ?> environment) throws Exception { > Reference localObject1; > if (obj instanceof Reference) { > localObject1 = (Reference) obj; > Object fruit = localObject1.get("fruit").getContent(); > return new Fruit((String)fruit); > } else { > return obj; > } > } > } > Fruit f = new Fruit("apple"); > context.bind("apple", f); > Fruit f1 = (Fruit)context.lookup("apple"); -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4365) jboss-ejb-container-interceptors_1_0.xsd is invalid

by Sande Gilda (JIRA)

Sande Gilda created WFLY-4365: --------------------------------- Summary: jboss-ejb-container-interceptors_1_0.xsd is invalid Key: WFLY-4365 URL: https://issues.jboss.org/browse/WFLY-4365 Project: WildFly Issue Type: Bug Components: EJB Reporter: Sande Gilda Importing the ejb-security-interceptors [1] quickstart into JBoss Developer Studio results in the following jboss-ejb3.xml validation errors. cvc-complex-type.2.4.a: Invalid content was found starting with element 'jee:interceptor-binding'. One of '{"http://java.sun.com/xml/ns/javaee":description, "http://java.sun.com/xml/ns/javaee":ejb-name}' is expected. jboss-ejb3.xml /jboss-ejb-security-interceptors/src/main/resources/META-INF line 31 XML Problem jboss-ejb-security-interceptor source is here: https://github.com/jboss-developer/jboss-eap-quickstarts/tree/6.4.x-devel... The quickstart bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=1178748 The related bug for the invalid schema for JBoss EAP 6.4 is here: https://bugzilla.redhat.com/show_bug.cgi?id=1193948 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-686) Documentation build: Upgrade pressgang-tools from 2 to 3

by Petr Široký (JIRA)

[ https://issues.jboss.org/browse/DROOLS-686?page=com.atlassian.jira.plugin... ] Petr Široký commented on DROOLS-686: ------------------------------------ There are some minor tweaks required for the plugin. I will send PR with changes that needs to applied after upgrade to jdocbook-core:1.1.1. > Documentation build: Upgrade pressgang-tools from 2 to 3 > -------------------------------------------------------- > > Key: DROOLS-686 > URL: https://issues.jboss.org/browse/DROOLS-686 > Project: Drools > Issue Type: Task > Reporter: Geoffrey De Smet > Assignee: Petr Široký > > We're still using pressgang-tools 2: > https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/pom.... > but some years ago pressgang-tools 3.x was build and released (by Steve Ebersole), which fixes some issues and enables some new features (such as topics in docbook): > https://github.com/pressgang/pressgang-tools > However, pressgang-tools 3.x has an important regression in combination with the maven-docbook-plugin 2.3.8, which prevents building offline, which is a blocker for us: > https://issues.jboss.org/browse/PRESSGANG-79 > The interesting note is that the gradle-docbook-plugin does build offline, and that both plugins (maven and gradle) use the same jdocbook-core: > https://github.com/pressgang > Goal: Fix that jira in maven-docbook-plugin and/or pressgang-tools, so droolsjbpm can upgrade to pressgang-tools 3.x. This is probably not easy. > The reason that it doesn't build offline, is because the xslt's contain full-url imports, so it reaches out to download those, but the jdocbook-core is able to intercepts to calls and reroute them to the local resources in the pressgang-tools jar (instead of downloading them from the internet). For some reason that works (probably configured correctly) for the gradle plugin, but not for the maven plugin. It's also strange that the maven plugin does work correctly with pressgang 2 jars. > In any case, the build should work offline (and doing "mvn -o" alone doesn't suffice to prove it, because the -o is ignored for the xslt stuff), plug out the network cable to verify it builds offline. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-334) "Ignore failure" for management operations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-334?page=com.atlassian.jira.plugin... ] Brian Stansberry resolved WFCORE-334. ------------------------------------- Resolution: Won't Fix This isn't practical on the server side, and if it isn't done server-side it won't help the CLI batch case, which AIUI is the goal. Ignoring a failure in a batch means discarding any interim changes that op made before the failure was detected and proceeding as if the op never existed. That cannot be done feasibly in any sort of consistent manner. Consistent meaning always works, not just for certain cases where the op failed before making any changes. > "Ignore failure" for management operations > ------------------------------------------ > > Key: WFCORE-334 > URL: https://issues.jboss.org/browse/WFCORE-334 > Project: WildFly Core > Issue Type: Feature Request > Components: Domain Management > Reporter: Ondrej Zizka > > Most operations don't follow any "overwrite" concept. > To emulate it, one needs to check for existence of a resource, conditionally delete it, and then create the new one. > This is not easily applicable in a batch. > Implementing overwrite for all actions would be tedious. > But this could help: > Another "standard" property (similar to {{address}} and {{op-name}}) "onFail=ignore" or such, which would make the operation not fail if an exception occurs. A short CLI syntax could be a '?' at the end of operation's name: > {code} > /foo=bar/boo=baz:remove?() > {code} > This would allow mgmt API users to queue a removing operation without knowing if it exists; thus, effectively, doing an overwrite. -- 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