[JBoss JIRA] (WFLY-4402) Fails to load JAX-RS Application class if deployment runtime name is changed
by Abhijit Sarkar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4402?page=com.atlassian.jira.plugin.... ]
Abhijit Sarkar updated WFLY-4402:
---------------------------------
Attachment: Screen Shot 2015-03-03 at 11.03.45 PM.png
> Fails to load JAX-RS Application class if deployment runtime name is changed
> ----------------------------------------------------------------------------
>
> Key: WFLY-4402
> URL: https://issues.jboss.org/browse/WFLY-4402
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final
> Environment: Oracle JDK 1.8.0_25
> Reporter: Abhijit Sarkar
> Assignee: David Lloyd
> Priority: Critical
> Attachments: availability-service-0.0.1-SNAPSHOT.war, Screen Shot 2015-03-03 at 11.03.45 PM.png
>
>
> If the runtime name is modified during deployment, it fails with a {{ClassNotFoundException}}. The runtime name determines the context root so in most practical cases, it'd be different from the archive name. Seems related to WFLY-1521 which was closed.
> {code}
> wildfly-server-8.2.0.Final.jar:8.2.0.Final]
> ... 5 more
> Caused by: java.lang.ClassNotFoundException: name.abhijitsarkar.microservices.availability.AvailabilityApp from [Module "deployment.availability-service:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4402) Fails to load JAX-RS Application class if deployment runtime name is changed
by Abhijit Sarkar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4402?page=com.atlassian.jira.plugin.... ]
Abhijit Sarkar reopened WFLY-4402:
----------------------------------
Attaching a screenshot to assist in troubleshooting.
> Fails to load JAX-RS Application class if deployment runtime name is changed
> ----------------------------------------------------------------------------
>
> Key: WFLY-4402
> URL: https://issues.jboss.org/browse/WFLY-4402
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final
> Environment: Oracle JDK 1.8.0_25
> Reporter: Abhijit Sarkar
> Assignee: David Lloyd
> Priority: Critical
> Attachments: availability-service-0.0.1-SNAPSHOT.war
>
>
> If the runtime name is modified during deployment, it fails with a {{ClassNotFoundException}}. The runtime name determines the context root so in most practical cases, it'd be different from the archive name. Seems related to WFLY-1521 which was closed.
> {code}
> wildfly-server-8.2.0.Final.jar:8.2.0.Final]
> ... 5 more
> Caused by: java.lang.ClassNotFoundException: name.abhijitsarkar.microservices.availability.AvailabilityApp from [Module "deployment.availability-service:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4402) Fails to load JAX-RS Application class if deployment runtime name is changed
by Abhijit Sarkar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4402?page=com.atlassian.jira.plugin.... ]
Abhijit Sarkar edited comment on WFLY-4402 at 3/4/15 12:15 AM:
---------------------------------------------------------------
[~swd847] There appears to be a not-so-obvious disconnect between what we're doing. Just humor me and please try the following steps exactly as laid out.
# Download 8.2.0.Final if you don't already have it.
# Start it with `standalone.sh`.
# Log into the management console (requires creating an admin user but you already know that).
# Starting from "create deployment", upload the war file attached. Change the runtime name and check the enable box. Before you hit the save button, the screen should look like the attached screenshot (if I can attach it, not sure, as the ticket has been closed).
# Look at the console for errors.
Edit: In order to attach the screenshot, I'm having to reopen the issue. Feel free to close if you've followed the steps and didn't see the error.
was (Author: abhi0123):
[~swd847] There appears to be a not-so-obvious disconnect between what we're doing. Just humor me and please try the following steps exactly as laid out.
# Download 8.2.0.Final if you don't already have it.
# Start it with `standalone.sh`.
# Log into the management console (requires creating an admin user but you already know that).
# Starting from "create deployment", upload the war file attached. Change the runtime name and check the enable box. Before you hit the save button, the screen should look like the attached screenshot (if I can attach it, not sure, as the ticket has been closed).
# Look at the console for errors.
> Fails to load JAX-RS Application class if deployment runtime name is changed
> ----------------------------------------------------------------------------
>
> Key: WFLY-4402
> URL: https://issues.jboss.org/browse/WFLY-4402
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final
> Environment: Oracle JDK 1.8.0_25
> Reporter: Abhijit Sarkar
> Assignee: David Lloyd
> Priority: Critical
> Attachments: availability-service-0.0.1-SNAPSHOT.war
>
>
> If the runtime name is modified during deployment, it fails with a {{ClassNotFoundException}}. The runtime name determines the context root so in most practical cases, it'd be different from the archive name. Seems related to WFLY-1521 which was closed.
> {code}
> wildfly-server-8.2.0.Final.jar:8.2.0.Final]
> ... 5 more
> Caused by: java.lang.ClassNotFoundException: name.abhijitsarkar.microservices.availability.AvailabilityApp from [Module "deployment.availability-service:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4402) Fails to load JAX-RS Application class if deployment runtime name is changed
by Abhijit Sarkar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4402?page=com.atlassian.jira.plugin.... ]
Abhijit Sarkar commented on WFLY-4402:
--------------------------------------
[~swd847] There appears to be a not-so-obvious disconnect between what we're doing. Just humor me and please try the following steps exactly as laid out.
# Download 8.2.0.Final if you don't already have it.
# Start it with `standalone.sh`.
# Log into the management console (requires creating an admin user but you already know that).
# Starting from "create deployment", upload the war file attached. Change the runtime name and check the enable box. Before you hit the save button, the screen should look like the attached screenshot (if I can attach it, not sure, as the ticket has been closed).
# Look at the console for errors.
> Fails to load JAX-RS Application class if deployment runtime name is changed
> ----------------------------------------------------------------------------
>
> Key: WFLY-4402
> URL: https://issues.jboss.org/browse/WFLY-4402
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final
> Environment: Oracle JDK 1.8.0_25
> Reporter: Abhijit Sarkar
> Assignee: David Lloyd
> Priority: Critical
> Attachments: availability-service-0.0.1-SNAPSHOT.war
>
>
> If the runtime name is modified during deployment, it fails with a {{ClassNotFoundException}}. The runtime name determines the context root so in most practical cases, it'd be different from the archive name. Seems related to WFLY-1521 which was closed.
> {code}
> wildfly-server-8.2.0.Final.jar:8.2.0.Final]
> ... 5 more
> Caused by: java.lang.ClassNotFoundException: name.abhijitsarkar.microservices.availability.AvailabilityApp from [Module "deployment.availability-service:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[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 edited comment on WFLY-4393 at 3/4/15 12:14 AM:
------------------------------------------------------------------
I found the following implementation in SOAPMessageContextImpl.java.
rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/soap/SOAPMessageContextImpl.java:
{noformat}
public Object get(Object key) {
Object o = super.get(key);
if (MessageContext.HTTP_RESPONSE_HEADERS.equals(key)
|| MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
Map<?, ?> mp = (Map<?, ?>)o;
if (mp != null) {
if (mp.isEmpty()) {
return null;
}
if (!isRequestor() && isOutbound() && MessageContext.HTTP_RESPONSE_HEADERS.equals(key)) {
return null;
}
if (isRequestor() && isOutbound() && MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
return null;
}
{noformat}
It results in HTTP_REQUEST_HEADERS is always null, when the handler chain is in client-side outbound processing.
JSR224 spec does not apparently say when it is available. But I think it is not necessary to hide it, for compatibility with the Java SE default implementations.
was (Author: nishigaya):
I found the following implementation in SOAPMessageContextImpl.java.
rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/soap/SOAPMessageContextImpl.java:
public Object get(Object key) {
Object o = super.get(key);
if (MessageContext.HTTP_RESPONSE_HEADERS.equals(key)
|| MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
Map<?, ?> mp = (Map<?, ?>)o;
if (mp != null) {
if (mp.isEmpty()) {
return null;
}
if (!isRequestor() && isOutbound() && MessageContext.HTTP_RESPONSE_HEADERS.equals(key)) {
return null;
}
if (isRequestor() && isOutbound() && MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
return null;
}
It results in HTTP_REQUEST_HEADERS is always null, when the handler chain is in client-side outbound processing.
JSR224 spec does not apparently say when it is available. But I think it is not necessary to hide it, for compatibility with the Java SE default implementations.
> 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: Alessio Soldano
> 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, 3 months
[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 commented on WFLY-4393:
-----------------------------------------
I found the following implementation in SOAPMessageContextImpl.java.
rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/soap/SOAPMessageContextImpl.java:
public Object get(Object key) {
Object o = super.get(key);
if (MessageContext.HTTP_RESPONSE_HEADERS.equals(key)
|| MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
Map<?, ?> mp = (Map<?, ?>)o;
if (mp != null) {
if (mp.isEmpty()) {
return null;
}
if (!isRequestor() && isOutbound() && MessageContext.HTTP_RESPONSE_HEADERS.equals(key)) {
return null;
}
if (isRequestor() && isOutbound() && MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
return null;
}
It results in HTTP_REQUEST_HEADERS is always null, when the handler chain is in client-side outbound processing.
JSR224 spec does not apparently say when it is available. But I think it is not necessary to hide it, for compatibility with the Java SE default implementations.
> 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: Alessio Soldano
> 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, 3 months
[JBoss JIRA] (WFLY-4402) Fails to load JAX-RS Application class if deployment runtime name is changed
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4402?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-4402.
----------------------------------
Resolution: Cannot Reproduce Bug
I just tested this against upstream and I cannot reproduce it.
> Fails to load JAX-RS Application class if deployment runtime name is changed
> ----------------------------------------------------------------------------
>
> Key: WFLY-4402
> URL: https://issues.jboss.org/browse/WFLY-4402
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final
> Environment: Oracle JDK 1.8.0_25
> Reporter: Abhijit Sarkar
> Assignee: David Lloyd
> Priority: Critical
> Attachments: availability-service-0.0.1-SNAPSHOT.war
>
>
> If the runtime name is modified during deployment, it fails with a {{ClassNotFoundException}}. The runtime name determines the context root so in most practical cases, it'd be different from the archive name. Seems related to WFLY-1521 which was closed.
> {code}
> wildfly-server-8.2.0.Final.jar:8.2.0.Final]
> ... 5 more
> Caused by: java.lang.ClassNotFoundException: name.abhijitsarkar.microservices.availability.AvailabilityApp from [Module "deployment.availability-service:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (JBJCA-1251) Exclude decrementer policy for CRI pools
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-1251:
--------------------------------------
Summary: Exclude decrementer policy for CRI pools
Key: JBJCA-1251
URL: https://issues.jboss.org/browse/JBJCA-1251
Project: IronJacamar
Issue Type: Task
Components: Core
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Fix For: 1.2.3.Final
Otherwise there could be configurations where the pools never would empty
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months