[JBoss JIRA] (WFLY-4331) EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4331?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4331:
-----------------------------------------------
Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1188420|https://bugzilla.redhat.com/show_bug.cgi?id=1188420] from ASSIGNED to POST
> EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-4331
> URL: https://issues.jboss.org/browse/WFLY-4331
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 9.0.0.Beta1
>
>
> When invoking EJB asynchronous in different deployments and returning a POJO object, which will be retrieved using future.get, we have ClassCastException error.
> {code}
> 12:53:50,147 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /testejb-web/async: java.lang.ClassCastException: rh.test.ReturnObject cannot be cast to rh.test.ReturnObject
> at rh.test.AsyncServlet.doGet(AsyncServlet.java:29) [classes:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-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.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> 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.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> 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.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:259) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:246) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:75) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:165) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:737) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4523) On Windows, setting the JAVA_OPTS variable is not
by Tom Kelley (JIRA)
Tom Kelley created WFLY-4523:
--------------------------------
Summary: On Windows, setting the JAVA_OPTS variable is not
Key: WFLY-4523
URL: https://issues.jboss.org/browse/WFLY-4523
Project: WildFly
Issue Type: Bug
Components: CLI
Affects Versions: 9.0.0.Alpha1
Environment: Windows 7 x64, JRE was bundled with JDK 8 u40 x64.
Hardware specs:
CPU: Intel Core i7-3720QM CPU @ 2.60 GHz
RAM: 16.0 GB
GPU: NVIDIA Quadro K1000M
Others upon request.
Reporter: Tom Kelley
Assignee: Alexey Loubyansky
Priority: Minor
{warn} This issue was copy/pasted from a github issue [here|https://github.com/wildfly/wildfly/issues/7352]. I apologize for 1) the issue duplication, 2) the length of the issue, 3) any poor communication that the transcription caused. {warn}
My company uses JBoss AS, and I have a copy on my local machine. In setting it up, I wrote a small script that lives in the bin directory and looks something like this:
{code}
@rem Delete current log file
del /F /Q ..\standalone\log\server.log
@rem Set Java Opts because I want to
set JAVA_OPTS="-XX:+TieredCompilation -XX:+UseCompressedOops -Dprogram.name=standalone.bat -Xms1303M -Xmx1303M -XX:MaxPermSize=256M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -agentlib:jdwp=transport=dt_socket,server=y,suspend=n"
@rem Set the new Java Home
set JAVA_HOME=C:\bin\java\jdk8_u40_64\jre
@rem Run Jboss
standalone.bat -c=standalone-full.xml --debug
{code}
I noticed when I was starting the server that the JAVA_OPTS in the debug text were not what I was passing in. I figured I could get to the bottom of what was going on, so I started digging in. My investigation led me to standalone.conf.bat, which looks like this:
{code}
rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters)
rem set PRESERVE_JAVA_OPTS=true
if not "x%JAVA_OPTS%" == "x" (
echo "JAVA_OPTS already set in environment; overriding default settings with values: %JAVA_OPTS%"
goto JAVA_OPTS_SET
)
{code}
This is very interesting. This snippet of code appears to be a bug. As someone who has worked with batch files, I believe that the correct code should look like this:
{code}
rem Uncomment the following line to disable manipulation of JAVA_OPTS (JVM parameters)
rem set PRESERVE_JAVA_OPTS=true
if not "x"%JAVA_OPTS% == "x" (
echo "JAVA_OPTS already set in environment; overriding default settings with values: %JAVA_OPTS%"
goto JAVA_OPTS_SET
)
{code}
You must be thinking, "if you know how to do this, why don't you just make the change yourself? It seems trivial." I would, but I'm not able to find the batch file in the source tree. It appears (to me) that the batch file is generated, and I don't know what to start looking for in order to fix this issue on my own.
As such, I've created a test batch file (meant to be run on Windows) that I've attached to this Issue. When the issue is fixed, it should output something like this:
{code}
Calling "C:\bin\wildfly\src\wildfly\build\target\wildfly-9.0.0.CR1-SNAPSHOT\bin\standalone.conf.bat"
"JAVA_OPTS already set in environment; overriding default settings with values: "Look at me. LOOK AT ME. I am the JAVA_OPTS now.""
Setting JAVA property to "C:\bin\java\jdk8_u40_64\jre\bin\java"
===============================================================================
JBoss Bootstrap Environment
JBOSS_HOME: "C:\bin\wildfly\src\wildfly\build\target\wildfly-9.0.0.CR1-SNAPSHOT"
JAVA: "C:\bin\java\jdk8_u40_64\jre\bin\java"
JAVA_OPTS: "-Dprogram.name=standalone.bat "Look at me. LOOK AT ME. I am the JAVA_OPTS now.""
===============================================================================
Error: Could not find or load main class Look at me. LOOK AT ME. I am the JAVA_OPTS now.
{code}
The batch file can be acquired [here|https://cloud.githubusercontent.com/assets/2186874/7147925/844bc00c-...], just save the link as a batch file, or save it and change the extension (the same way that we get around email filters that don't let us send *.exe's). The way that I ran this was to put the batch file at the root of the Wildfly directory and then call it using window's CMD. The test case does several things:
1. Maven clean
2. Call build.bat
3. Set a JAVA_OPTS system variable
4. Call the standalone.bat in the new version of Wildfly that was created in step 2 (as long as the target dir is still wildfly-9.0.0.CR1-SNAPSHOT).
I would love to take lead on fixing this, but I'm not sure where to start. If someone could give me a point in the right direction, that would be great. Thanks.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4522) Add 'com/sun/org/apache/xml/internal/security'++ to 'sun.jdk' module
by Edvin Syse (JIRA)
Edvin Syse created WFLY-4522:
--------------------------------
Summary: Add 'com/sun/org/apache/xml/internal/security'++ to 'sun.jdk' module
Key: WFLY-4522
URL: https://issues.jboss.org/browse/WFLY-4522
Project: WildFly
Issue Type: Task
Components: Class Loading, Web Services
Affects Versions: 9.0.0.Beta2
Reporter: Edvin Syse
Assignee: David Lloyd
The following paths are needed for xws-security:
com/sun/org/apache/xml/internal/security
com/sun/org/apache/xml/internal/security/exceptions
com/sun/org/apache/xerces/internal/jaxp
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4444) Ability to set WSDL URL
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-4444?page=com.atlassian.jira.plugin.... ]
Alessio Soldano edited comment on WFLY-4444 at 4/15/15 11:27 AM:
-----------------------------------------------------------------
OK, given the comments & explanations above I think I can mark this again as solved. If there's still something to discuss, just comment below.
was (Author: asoldano):
OK, given the comment & explanations above I think I can mark this again as solved. If there's still something to discuss, just comment below.
> Ability to set WSDL URL
> -----------------------
>
> Key: WFLY-4444
> URL: https://issues.jboss.org/browse/WFLY-4444
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Reporter: John Ament
> Assignee: Alessio Soldano
>
> There's no way to correctly set a WSDL URL. The properties are:
> {code}
> <modify-wsdl-address>true</modify-wsdl-address>
> <wsdl-host>${public.app.host:localhost}</wsdl-host>
> <wsdl-port>${public.http.port:80}</wsdl-port>
> <wsdl-secure-port>${public.https.port:443}</wsdl-secure-port>
> {code}
> We need a way to set the WSDL URL, regardless of the protocol used. The issue being that our app servers run on HTTP, but the incoming request to the first load balancer is over HTTPS. The result is that the WSDL generated includes http://public-host:80/ instead of https://public-host:443/
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4444) Ability to set WSDL URL
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-4444?page=com.atlassian.jira.plugin.... ]
Alessio Soldano resolved WFLY-4444.
-----------------------------------
Resolution: Out of Date
> Ability to set WSDL URL
> -----------------------
>
> Key: WFLY-4444
> URL: https://issues.jboss.org/browse/WFLY-4444
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Reporter: John Ament
> Assignee: Alessio Soldano
>
> There's no way to correctly set a WSDL URL. The properties are:
> {code}
> <modify-wsdl-address>true</modify-wsdl-address>
> <wsdl-host>${public.app.host:localhost}</wsdl-host>
> <wsdl-port>${public.http.port:80}</wsdl-port>
> <wsdl-secure-port>${public.https.port:443}</wsdl-secure-port>
> {code}
> We need a way to set the WSDL URL, regardless of the protocol used. The issue being that our app servers run on HTTP, but the incoming request to the first load balancer is over HTTPS. The result is that the WSDL generated includes http://public-host:80/ instead of https://public-host:443/
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (WFLY-4444) Ability to set WSDL URL
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-4444?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-4444:
---------------------------------------
OK, given the comment & explanations above I think I can mark this again as solved. If there's still something to discuss, just comment below.
> Ability to set WSDL URL
> -----------------------
>
> Key: WFLY-4444
> URL: https://issues.jboss.org/browse/WFLY-4444
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Services
> Affects Versions: 8.2.0.Final
> Reporter: John Ament
> Assignee: Alessio Soldano
>
> There's no way to correctly set a WSDL URL. The properties are:
> {code}
> <modify-wsdl-address>true</modify-wsdl-address>
> <wsdl-host>${public.app.host:localhost}</wsdl-host>
> <wsdl-port>${public.http.port:80}</wsdl-port>
> <wsdl-secure-port>${public.https.port:443}</wsdl-secure-port>
> {code}
> We need a way to set the WSDL URL, regardless of the protocol used. The issue being that our app servers run on HTTP, but the incoming request to the first load balancer is over HTTPS. The result is that the WSDL generated includes http://public-host:80/ instead of https://public-host:443/
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
