[JBoss JIRA] (DROOLS-729) Android Support
by Mark Proctor (JIRA)
[ https://issues.jboss.org/browse/DROOLS-729?page=com.atlassian.jira.plugin... ]
Mark Proctor commented on DROOLS-729:
-------------------------------------
Can you come onto irc and speak to Mario (mfusco). This will make it much easier to discuss all the related issues and for us to figure out how to integrate your changes.
http://drools.org/community/chat.html
> Android Support
> ---------------
>
> Key: DROOLS-729
> URL: https://issues.jboss.org/browse/DROOLS-729
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 6.0.1.Final
> Environment: Android
> Reporter: Mark Kedzierski
> Assignee: Mario Fusco
> Priority: Optional
> Labels: Android
>
> I've done some work porting Drools 6.0.1.Final to work on Android. My current effort uses Dex classloaders for all generated classes. Precompiled rule packages execute on Android with either java or mvel dialect.
> code:
> http://www.github.com/kedzie/drools-android
> http://www.github.com/kedzie/drools-android-sample
> Features:
> -Dex classloaders for all generated classes
> -Roboguice integration for injecting knowledge bases from precompiled packages
> -Maven plugin which pre-compiles rule packages
> Issues:
> -Unit tests don't work because it always uses dex classloader, which doesn't work on a desktop system
> -Haven't tested drools-compiler on android platform
> I am wondering how to move forward and contribute this code. I think it would be ideal if the same codebase worked on both desktop and android platforms. Otherwise it would need to be a seperate fork. Also how to manage unit testing in the Android version. Any thoughts welcome.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (WFLY-4393) Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers
by Takashi Nishigaya (JIRA)
[ https://issues.jboss.org/browse/WFLY-4393?page=com.atlassian.jira.plugin.... ]
Takashi Nishigaya updated WFLY-4393:
------------------------------------
Attachment: handler_header_chain.zip
> Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-4393
> URL: https://issues.jboss.org/browse/WFLY-4393
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Reporter: Takashi Nishigaya
> Assignee: Jason Greene
> Attachments: handler_header_chain.zip
>
>
> CXF runtime does NOT propagate JAX-WS standard context value MessageContext.HTTP_REQUEST_HEADERS to the subsequent client-side SOAP handlers. For instance,
> 1. The first client handler puts the newly created HTTP request header map that contains the custom header 'foo' in the message context.
> 2. The second client handler can not refer to the custom header 'foo' added in the step 1. The HTTP request header map in the message context is null.
> The weird thing is that the custom header added in the step 1 is correctly received by the server-side web services.
> The both of Java SE default JAX-WS implementations and GlassFish correctly share HTTP_REQUEST_HEADERS map between handlers.
> Please check the attached test case and compare the two test case. The method testHandlerChainOnServer() tests the case that the client is running on the container. On the other hand, testHandlerChainOnStandalone() tests the standalone client case.
> In order to reproduce the issue:
> $ mvm clean test -P wildly-managed (or -P wildly-remote)
> Additionally, this behavior is the same in EAP 6.3.3.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[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 commented on WFLY-4362:
-----------------------------------------------
Radim Hatlapatka <rhatlapa(a)redhat.com> changed the Status of [bug 1193553|https://bugzilla.redhat.com/show_bug.cgi?id=1193553] from ON_QA to VERIFIED
> 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("<p>" + n + "</p>"));
> 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("<p>" + n + "</p>"));
> 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("<p>" + n + "</p>"));
> 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("<p>" + n + "</p>"));
> 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("<p>" + n + "</p>"));
> 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("<p>" + n + "</p>"));
> 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)
9 years, 1 month
[JBoss JIRA] (WFLY-4393) Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers
by Takashi Nishigaya (JIRA)
[ https://issues.jboss.org/browse/WFLY-4393?page=com.atlassian.jira.plugin.... ]
Takashi Nishigaya updated WFLY-4393:
------------------------------------
Description:
CXF runtime does NOT propagate JAX-WS standard context value MessageContext.HTTP_REQUEST_HEADERS to the subsequent client-side SOAP handlers. For instance,
1. The first client handler puts the newly created HTTP request header map that contains the custom header 'foo' in the message context.
2. The second client handler can not refer to the custom header 'foo' added in the step 1. The HTTP request header map in the message context is null.
The weird thing is that the custom header added in the step 1 is correctly received by the server-side web services.
The both of Java SE default JAX-WS implementations and GlassFish correctly share HTTP_REQUEST_HEADERS map between handlers.
Please check the attached test case and compare the two test case. The method testHandlerChainOnServer() tests the case that the client is running on the container. On the other hand, testHandlerChainOnStandalone() tests the standalone client case.
In order to reproduce the issue:
$ mvm clean test -P wildly-managed (or -P wildly-remote)
Additionally, this behavior is the same in EAP 6.3.3.
> Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-4393
> URL: https://issues.jboss.org/browse/WFLY-4393
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Reporter: Takashi Nishigaya
> Assignee: Jason Greene
>
> CXF runtime does NOT propagate JAX-WS standard context value MessageContext.HTTP_REQUEST_HEADERS to the subsequent client-side SOAP handlers. For instance,
> 1. The first client handler puts the newly created HTTP request header map that contains the custom header 'foo' in the message context.
> 2. The second client handler can not refer to the custom header 'foo' added in the step 1. The HTTP request header map in the message context is null.
> The weird thing is that the custom header added in the step 1 is correctly received by the server-side web services.
> The both of Java SE default JAX-WS implementations and GlassFish correctly share HTTP_REQUEST_HEADERS map between handlers.
> Please check the attached test case and compare the two test case. The method testHandlerChainOnServer() tests the case that the client is running on the container. On the other hand, testHandlerChainOnStandalone() tests the standalone client case.
> In order to reproduce the issue:
> $ mvm clean test -P wildly-managed (or -P wildly-remote)
> Additionally, this behavior is the same in EAP 6.3.3.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (JGRP-1908) Optional Executing protocol behavior to not attempt to repeat tasks
by William Burns (JIRA)
[ https://issues.jboss.org/browse/JGRP-1908?page=com.atlassian.jira.plugin.... ]
William Burns commented on JGRP-1908:
-------------------------------------
[~belaban] if there is no response when you release the build, I would say just to close this out.
> Optional Executing protocol behavior to not attempt to repeat tasks
> -------------------------------------------------------------------
>
> Key: JGRP-1908
> URL: https://issues.jboss.org/browse/JGRP-1908
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Anuj Shah
> Assignee: William Burns
> Labels: executionservice
> Fix For: 3.6.3
>
>
> As discussed on forum:
> http://jgroups.1086181.n5.nabble.com/jgroups-users-ExecutionService-at-le...
> {quote}
> I've noticed that runnable tasks submitted to the ExecutionService can be run more than once!
> This would happen when a member executing the task is suspected and is removed from the cluster. The protocol handles this by resubmitting the request in Executing#handleView. I note the following JavaDoc
> // The person currently servicing our request has gone down
> // without completing so we have to keep our request alive by
> // sending ours back to the coordinator
> The problem is that there is no guarantee that the request was not completed.
> For my application a member executing the task had a absurdly long GC pause (30s) which meant it was temporarily removed from the cluster, when the pause completed it happily continued executing the task which had already been resubmitted and completed. The task in question involves modifying the database and is quite destructive, so you can imagine the fallout.
> I was hoping to get an opinion of if we think this behaviour is correct, especially since we are implementing a standard java,util.concurrent interface. (I couldn't find anything in the ExecutorService JavaDoc to say it is wrong though)
> Perhaps there could be control over the behaviour:
> * At least once - assumes task failed and resubmits
> * At most once - assumes task completed and cleans up - may not actually be complete
> * Exactly once - not sure if this is possible
> {quote}
> There is a simple change to exhibit the at least once behaviour by ignoring consumers that have left. I have the patch in my fork:
> https://github.com/anujshahwork/JGroups/commit/0f2c1f6f9ed57744841acdd192...
> Which my project is using. This can be wrapped in some simple configuration on the protocol to control the behaviour and would be a useful addition.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month
[JBoss JIRA] (JGRP-1917) FILE_PING: options to remove zombies
by Bela Ban (JIRA)
Bela Ban created JGRP-1917:
------------------------------
Summary: FILE_PING: options to remove zombies
Key: JGRP-1917
URL: https://issues.jboss.org/browse/JGRP-1917
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6.3
In {{FILE_PING}} and subclasses ({{S3_PING}}, {{GOOGLE_PING}}), coordinators write the files (e.g. {{A.list}} for coord {{A}}).
There's a shutdown hook that removes {{A.list}} when {{A}} crashes.
However, when a coordinator is killed by kill -9, the file {{A.list}} won't get removed.
The problem with this is that new members will read {{A.list}} and get delayed trying to ask {{A}} to join the cluster although {{A}}'s not alive anymore ({{B}} is and created {{B.list}}).
Possible solution: implement a mechanism similar to JGRP-1915 where a coordinator removes *all files* on a view change with leaving members, and then writes its file again.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 1 month