[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3560:
------------------------------
Component/s: Web (Undertow)
Forum Reference: https://community.jboss.org/message/879772
> Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3560
> URL: https://issues.jboss.org/browse/WFLY-3560
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Reporter: Gary Yang
> Assignee: Jason Greene
>
> Issue is described in https://community.jboss.org/thread/242415
> If client uses "Connection:keep-alive" and "Expect:100-continue" in HTTP request header and send multiple requests, Wildfly (including 8.0.0 and 8.1.0) throws following exception:
> {noformat}
> 2014-06-29 11:12:14,721 ERROR [io.undertow.request] (default task-26) Blocking request failed HttpServerExchange{ POST /enterprise/composite/postAndSend}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
> at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
> at io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.read(HttpContinueReadHandler.java:104)
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:181)
> at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:1897)
> at org.xnio.channels.Channels.readBlocking(Channels.java:294) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:138)
> at io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:218)
> at io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:589)
> at io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:69)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1363)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:183)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> {noformat}
>
> If there are multiple users sending this kind of requests, Wildfly eventually undeploy all applications.
> Here is a test code using Apache HTTP client
> {code:java}
> HttpPost request = new HttpPost(serverURL);
> for (int i=0; i<200; i++) {
> StringEntity input = new StringEntity (payLoad);
> input.setContentType("application/json");
> request.setHeader("Connection", "keep-alive");
> request.setHeader("Expect", "100-continue");
> request.setEntity(input);
> HttpResponse response = httpclient.execute(request);
> HttpEntity entity = response.getEntity();
>
> if (entity != null) {
> System.out.println("Response content length: " + entity.getContentLength());
> }
> EntityUtils.consume(entity);
>
> if (entity != null) {
> System.out.println("Response content length: " + entity.getContentLength());
> }
> EntityUtils.consume(entity);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3560:
------------------------------
Affects Version/s: 8.1.0.Final
8.0.0.Final
> Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3560
> URL: https://issues.jboss.org/browse/WFLY-3560
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Reporter: Gary Yang
> Assignee: Jason Greene
>
> Issue is described in https://community.jboss.org/thread/242415
> If client uses "Connection:keep-alive" and "Expect:100-continue" in HTTP request header and send multiple requests, Wildfly (including 8.0.0 and 8.1.0) throws following exception:
> {noformat}
> 2014-06-29 11:12:14,721 ERROR [io.undertow.request] (default task-26) Blocking request failed HttpServerExchange{ POST /enterprise/composite/postAndSend}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
> at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
> at io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.read(HttpContinueReadHandler.java:104)
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:181)
> at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:1897)
> at org.xnio.channels.Channels.readBlocking(Channels.java:294) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:138)
> at io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:218)
> at io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:589)
> at io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:69)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1363)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:183)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> {noformat}
>
> If there are multiple users sending this kind of requests, Wildfly eventually undeploy all applications.
> Here is a test code using Apache HTTP client
> {code:java}
> HttpPost request = new HttpPost(serverURL);
> for (int i=0; i<200; i++) {
> StringEntity input = new StringEntity (payLoad);
> input.setContentType("application/json");
> request.setHeader("Connection", "keep-alive");
> request.setHeader("Expect", "100-continue");
> request.setEntity(input);
> HttpResponse response = httpclient.execute(request);
> HttpEntity entity = response.getEntity();
>
> if (entity != null) {
> System.out.println("Response content length: " + entity.getContentLength());
> }
> EntityUtils.consume(entity);
>
> if (entity != null) {
> System.out.println("Response content length: " + entity.getContentLength());
> }
> EntityUtils.consume(entity);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3560:
------------------------------
Description:
Issue is described in https://community.jboss.org/thread/242415
If client uses "Connection:keep-alive" and "Expect:100-continue" in HTTP request header and send multiple requests, Wildfly (including 8.0.0 and 8.1.0) throws following exception:
{noformat}
2014-06-29 11:12:14,721 ERROR [io.undertow.request] (default task-26) Blocking request failed HttpServerExchange{ POST /enterprise/composite/postAndSend}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
at io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.read(HttpContinueReadHandler.java:104)
at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:181)
at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:1897)
at org.xnio.channels.Channels.readBlocking(Channels.java:294) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:138)
at io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:218)
at io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:589)
at io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:69)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1363)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:183)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
{noformat}
If there are multiple users sending this kind of requests, Wildfly eventually undeploy all applications.
Here is a test code using Apache HTTP client
{code:java}
HttpPost request = new HttpPost(serverURL);
for (int i=0; i<200; i++) {
StringEntity input = new StringEntity (payLoad);
input.setContentType("application/json");
request.setHeader("Connection", "keep-alive");
request.setHeader("Expect", "100-continue");
request.setEntity(input);
HttpResponse response = httpclient.execute(request);
HttpEntity entity = response.getEntity();
if (entity != null) {
System.out.println("Response content length: " + entity.getContentLength());
}
EntityUtils.consume(entity);
if (entity != null) {
System.out.println("Response content length: " + entity.getContentLength());
}
EntityUtils.consume(entity);
}
{code}
was:
Issue is described in https://community.jboss.org/thread/242415
If client uses "Connection:keep-alive" and "Expect:100-continue" in HTTP request header and send multiple requests, Wildfly (including 8.0.0 and 8.1.0) throws following exception:
2014-06-29 11:12:14,721 ERROR [io.undertow.request] (default task-26) Blocking request failed HttpServerExchange{ POST /enterprise/composite/postAndSend}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
at io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.read(HttpContinueReadHandler.java:104)
at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:181)
at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:1897)
at org.xnio.channels.Channels.readBlocking(Channels.java:294) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:138)
at io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:218)
at io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:589)
at io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:69)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1363)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:183)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
If there are multiple users sending this kind of requests, Wildfly eventually undeploy all applications.
Here is a test code using Apache HTTP client
HttpPost request = new HttpPost(serverURL);
for (int i=0; i<200; i++) {
StringEntity input = new StringEntity (payLoad);
input.setContentType("application/json");
request.setHeader("Connection", "keep-alive");
request.setHeader("Expect", "100-continue");
request.setEntity(input);
HttpResponse response = httpclient.execute(request);
HttpEntity entity = response.getEntity();
if (entity != null) {
System.out.println("Response content length: " + entity.getContentLength());
}
EntityUtils.consume(entity);
if (entity != null) {
System.out.println("Response content length: " + entity.getContentLength());
}
EntityUtils.consume(entity);
}
> Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3560
> URL: https://issues.jboss.org/browse/WFLY-3560
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Final, 8.1.0.Final
> Reporter: Gary Yang
> Assignee: Jason Greene
>
> Issue is described in https://community.jboss.org/thread/242415
> If client uses "Connection:keep-alive" and "Expect:100-continue" in HTTP request header and send multiple requests, Wildfly (including 8.0.0 and 8.1.0) throws following exception:
> {noformat}
> 2014-06-29 11:12:14,721 ERROR [io.undertow.request] (default task-26) Blocking request failed HttpServerExchange{ POST /enterprise/composite/postAndSend}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
> at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
> at io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.read(HttpContinueReadHandler.java:104)
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:181)
> at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:1897)
> at org.xnio.channels.Channels.readBlocking(Channels.java:294) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:138)
> at io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:218)
> at io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:589)
> at io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:69)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1363)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:183)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> {noformat}
>
> If there are multiple users sending this kind of requests, Wildfly eventually undeploy all applications.
> Here is a test code using Apache HTTP client
> {code:java}
> HttpPost request = new HttpPost(serverURL);
> for (int i=0; i<200; i++) {
> StringEntity input = new StringEntity (payLoad);
> input.setContentType("application/json");
> request.setHeader("Connection", "keep-alive");
> request.setHeader("Expect", "100-continue");
> request.setEntity(input);
> HttpResponse response = httpclient.execute(request);
> HttpEntity entity = response.getEntity();
>
> if (entity != null) {
> System.out.println("Response content length: " + entity.getContentLength());
> }
> EntityUtils.consume(entity);
>
> if (entity != null) {
> System.out.println("Response content length: " + entity.getContentLength());
> }
> EntityUtils.consume(entity);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
by Gary Yang (JIRA)
[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ]
Gary Yang updated WFLY-3560:
----------------------------
Description:
Issue is described in https://community.jboss.org/thread/242415
If client uses "Connection:keep-alive" and "Expect:100-continue" in HTTP request header and send multiple requests, Wildfly (including 8.0.0 and 8.1.0) throws following exception:
2014-06-29 11:12:14,721 ERROR [io.undertow.request] (default task-26) Blocking request failed HttpServerExchange{ POST /enterprise/composite/postAndSend}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
at io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.read(HttpContinueReadHandler.java:104)
at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:181)
at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:1897)
at org.xnio.channels.Channels.readBlocking(Channels.java:294) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:138)
at io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:218)
at io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:589)
at io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:69)
at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1363)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:183)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
If there are multiple users sending this kind of requests, Wildfly eventually undeploy all applications.
Here is a test code using Apache HTTP client
HttpPost request = new HttpPost(serverURL);
for (int i=0; i<200; i++) {
StringEntity input = new StringEntity (payLoad);
input.setContentType("application/json");
request.setHeader("Connection", "keep-alive");
request.setHeader("Expect", "100-continue");
request.setEntity(input);
HttpResponse response = httpclient.execute(request);
HttpEntity entity = response.getEntity();
if (entity != null) {
System.out.println("Response content length: " + entity.getContentLength());
}
EntityUtils.consume(entity);
if (entity != null) {
System.out.println("Response content length: " + entity.getContentLength());
}
EntityUtils.consume(entity);
}
> Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
> -----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3560
> URL: https://issues.jboss.org/browse/WFLY-3560
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Gary Yang
> Assignee: Jason Greene
>
> Issue is described in https://community.jboss.org/thread/242415
> If client uses "Connection:keep-alive" and "Expect:100-continue" in HTTP request header and send multiple requests, Wildfly (including 8.0.0 and 8.1.0) throws following exception:
> 2014-06-29 11:12:14,721 ERROR [io.undertow.request] (default task-26) Blocking request failed HttpServerExchange{ POST /enterprise/composite/postAndSend}: java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
> at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:78)
> at io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.read(HttpContinueReadHandler.java:104)
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at io.undertow.channels.DetachableStreamSourceChannel.read(DetachableStreamSourceChannel.java:181)
> at io.undertow.server.HttpServerExchange$ReadDispatchChannel.read(HttpServerExchange.java:1897)
> at org.xnio.channels.Channels.readBlocking(Channels.java:294) [xnio-api-3.2.0.Final.jar:3.2.0.Final]
> at io.undertow.servlet.spec.ServletInputStreamImpl.readIntoBuffer(ServletInputStreamImpl.java:138)
> at io.undertow.servlet.spec.ServletInputStreamImpl.close(ServletInputStreamImpl.java:218)
> at io.undertow.servlet.spec.HttpServletRequestImpl.closeAndDrainRequest(HttpServletRequestImpl.java:589)
> at io.undertow.servlet.core.ServletBlockingHttpExchange.close(ServletBlockingHttpExchange.java:69)
> at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1363)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:183)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:687)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
>
> If there are multiple users sending this kind of requests, Wildfly eventually undeploy all applications.
> Here is a test code using Apache HTTP client
> HttpPost request = new HttpPost(serverURL);
> for (int i=0; i<200; i++) {
> StringEntity input = new StringEntity (payLoad);
> input.setContentType("application/json");
> request.setHeader("Connection", "keep-alive");
> request.setHeader("Expect", "100-continue");
> request.setEntity(input);
> HttpResponse response = httpclient.execute(request);
> HttpEntity entity = response.getEntity();
>
> if (entity != null) {
> System.out.println("Response content length: " + entity.getContentLength());
> }
> EntityUtils.consume(entity);
>
> if (entity != null) {
> System.out.println("Response content length: " + entity.getContentLength());
> }
> EntityUtils.consume(entity);
> }
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (WFLY-3478) subnet-match is completely broken
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3478?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3478:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1111578|https://bugzilla.redhat.com/show_bug.cgi?id=1111578] from ASSIGNED to CLOSED
> subnet-match is completely broken
> ---------------------------------
>
> Key: WFLY-3478
> URL: https://issues.jboss.org/browse/WFLY-3478
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.1.0.Final
> Reporter: Rich DiCroce
> Assignee: Ivo Studensky
> Fix For: 8.2.0.CR1, 9.0.0.Alpha1
>
>
> subnet-match does not respect the value attribute. Instead, it seems to just pick the first interface it finds. No matter what I specify as a value, even if it's a value that's complete nonsense and doesn't match any IP address on my system, e.g.
> {code:xml}
> <interface name="public">
> <subnet-match value="1.2.3.0/24"/>
> </interface>
> {code}
> the ports end up bound to the only interface that is currently connected
> {noformat}
> 14:45:16,740 INFO [stdout] (ServerService Thread Pool -- 40) -------------------------------------------------------------------
> 14:45:16,740 INFO [stdout] (ServerService Thread Pool -- 40) GMS: address=normandy/GamingPortal, cluster=GamingPortal, physical address=192.168.1.105:3100
> 14:45:16,741 INFO [stdout] (ServerService Thread Pool -- 40) -------------------------------------------------------------------
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (WFLY-2261) standalone.sh --debug without port number not working
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2261?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2261:
-----------------------------------------------
Pavel Slavicek <pslavice(a)redhat.com> changed the Status of [bug 1072227|https://bugzilla.redhat.com/show_bug.cgi?id=1072227] from ASSIGNED to CLOSED
> standalone.sh --debug without port number not working
> ------------------------------------------------------
>
> Key: WFLY-2261
> URL: https://issues.jboss.org/browse/WFLY-2261
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 8.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Jeff Mesnil
> Fix For: 8.1.0.CR1, 8.1.0.Final
>
>
> ./standalone.sh --debug port-num works, but it failed when omitting port number.
> sh -x standalone.sh --debug (expecting the default port 8787 to be used)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ' ""'
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone ''
> Listening for transport dt_socket at address: 8787
> 12:19:36,715 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:19:36,886 ERROR [stderr] (main) JBAS015801: Invalid option ''
> 12:19:36,893 INFO [stdout] (main)
> 12:19:36,893 INFO [stdout] (main) Usage: standalone.sh [args...]
> {noformat}
> sh -x standalone.sh --debug 8787 (the working command)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ''
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone
> Listening for transport dt_socket at address: 8787
> 12:20:39,251 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:20:39,626 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta2
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (JBASMP-58) jboss-as-maven-plugin freezes on authentication
by Judah Sosnick (JIRA)
[ https://issues.jboss.org/browse/JBASMP-58?page=com.atlassian.jira.plugin.... ]
Judah Sosnick commented on JBASMP-58:
-------------------------------------
Just to clarify, I can NOT get this plugin with any version. I still have the authentication hang issue, including with 7.4.Final and 7.5.Final.
> jboss-as-maven-plugin freezes on authentication
> -----------------------------------------------
>
> Key: JBASMP-58
> URL: https://issues.jboss.org/browse/JBASMP-58
> Project: JBoss AS Maven Plugins
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: deploy
> Affects Versions: 7.5.Final
> Environment: mac os x 10.8.5 & mac os x 10.9
> mvn 3.1.1
> Reporter: Julien Derveeuw
> Assignee: James Perkins
> Priority: Critical
>
> I have jboss 7.1.1 in standalone mode running on machine A (linux).
> I want to deploy remotely to it using client machine B @ mac os X 10.8.5 / JDK 1.7.0_45-b18.
> If I connect from B to A using {{jboss-cli}}, everything works fine, I am able to login.
> If I try to deploy from maven with this :
> {code:xml}
> <groupId>org.jboss.as.plugins</groupId>
> <artifactId>jboss-as-maven-plugin</artifactId>
> <version>7.5.Final</version>
> <configuration>
> <hostname>${deploy.jboss.host}</hostname>
> <port>${deploy.jboss.port}</port>
> <username>${deploy.jboss.user}</username>
> <password>${deploy.jboss.password}</password>
> </configuration>
> <executions>
> <execution>
> <phase>install</phase>
> <goals>
> <goal>deploy</goal>
> </goals>
> </execution>
> </executions>
> {code}
> plugin freezes indefinitely on
> {{Authenticating against security realm: ManagementRealm}}
> No more details are available with {{mvn -X}}
> If I remove the password or username from pom, it fails correctly with :
> {{The connection failed: Authentication failed: all available authentication mechanisms failed}}
> so it seems that the plugin somehow manages to connect to machine A.
> After digging on google, I ended up adding {{-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.KQueueSelectorProvider}} to mvn runner options because NIOs on jdk7@macosx is said to be buggy but it didn't help.
> More details :
> {code:title=mvn 3.1.1 output|borderStyle=solid}Nov 7, 2013 10:40:09 PM org.xnio.Xnio <clinit>
> INFO: XNIO Version 3.0.3.GA
> Nov 7, 2013 10:40:09 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.0.3.GA
> Nov 7, 2013 10:40:09 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 3.2.3.GA
> Authenticating against security realm: ManagementRealm
> {code}
> {code:title=jstack 7.1.1.Final|borderStyle=solid}
> "main" prio=5 tid=7f86d6800800 nid=0x1060f0000 in Object.wait() [1060ee000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:485)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - locked <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <7f4102a20> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get(AbstractModelControllerClient.java:363)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient$DelegatingCancellableAsyncFuture.get(AbstractModelControllerClient.java:317)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:137)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:81)
> at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.exists(StandaloneDeployment.java:175)
> at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.createPlan(StandaloneDeployment.java:108)
> at org.jboss.as.plugin.deployment.standalone.StandaloneDeployment.execute(StandaloneDeployment.java:133)
> at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:138)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
> {code:title=jstack 7.5.Final|borderStyle=solid}
> "main" prio=5 tid=7fceea001000 nid=0x10d4d0000 in Object.wait() [10d4ce000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:485)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - locked <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <7f42f2150> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.plugin.common.AbstractServerConnection.isDomainServer(AbstractServerConnection.java:234)
> at org.jboss.as.plugin.common.AbstractServerConnection.getClient(AbstractServerConnection.java:156)
> - locked <7f42f2230> (a java.lang.Object)
> at org.jboss.as.plugin.common.AbstractServerConnection.isDomainServer(AbstractServerConnection.java:133)
> - locked <7f42f2230> (a java.lang.Object)
> at org.jboss.as.plugin.deployment.AbstractDeployment.validate(AbstractDeployment.java:192)
> at org.jboss.as.plugin.deployment.AbstractDeployment.doExecute(AbstractDeployment.java:136)
> - locked <7f42f2230> (a java.lang.Object)
> at org.jboss.as.plugin.deployment.AbstractAppDeployment.doExecute(AbstractAppDeployment.java:70)
> at org.jboss.as.plugin.deployment.AbstractDeployment.execute(AbstractDeployment.java:111)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months
[JBoss JIRA] (JASSIST-226) automatical modification of class and method Annotation
by Paolo Paolo (JIRA)
[ https://issues.jboss.org/browse/JASSIST-226?page=com.atlassian.jira.plugi... ]
Paolo Paolo updated JASSIST-226:
--------------------------------
Description:
I'm using Javassist to create .class file at runtime. Every method of the created class must have a Java Annotation ("@annotation example") with an URI. The problem is that the Annotation class modifies automatically the URI by substituting slashes with dots.
//the Annotation String that I need
@RDFBean('http://www.semanticweb.org/pi/2014/5/test#Test')
//the resulting String
@RDFBean('http:..www.semanticweb.org.pi.2014.5.test#Test')
Is there a way to prevent this String modification?
I suppose it's related to the different notation between a file path and a Java package.
This is the code:
ClassPool pool = ClassPool.getDefault();
CtClass cc = pool.makeClass(className);
ClassFile ccFile = cc.getClassFile();
ConstPool constpool = ccFile.getConstPool();
// create the annotation
AnnotationsAttribute attr = new AnnotationsAttribute(constpool, AnnotationsAttribute.visibleTag);
// classLocalName contains: http://www.semanticweb.org/pi/2014/5/test#Test
Annotation annot = new Annotation("RDFBean('" + classLocalName + "')", constpool);
attr.addAnnotation(annot);
ccFile.addAttribute(attr);
was:
I'm using Javassist to create .class file at runtime. Every method of the created class must have a Java Annotation ("@annotation example") with an URI. The problem is that the Annotation class modifies automatically the URI by substituting slashes with dots.
//the Annotation String that I need
@RDFBean('http://www.semanticweb.org/pi/2014/5/test#Test')
//the resulting String
@RDFBean('http:..www.semanticweb.org.pi.2014.5.test#Test')
Is there a way to prevent this String modification?
I suppose it's related to the different notation between a file path and a Java package.
This is the code:
ClassPool pool = ClassPool.getDefault();
CtClass cc = pool.makeClass(className);
ClassFile ccFile = cc.getClassFile();
ConstPool constpool = ccFile.getConstPool();
// create the annotation
AnnotationsAttribute attr = new AnnotationsAttribute(constpool, AnnotationsAttribute.visibleTag);
// classLocalName contains: http://www.semanticweb.org/pi/2014/5/test#Test
Annotation annot = new Annotation("RDFBean('"+classLocalName+"')", constpool);
attr.addAnnotation(annot);
ccFile.addAttribute(attr);
> automatical modification of class and method Annotation
> -------------------------------------------------------
>
> Key: JASSIST-226
> URL: https://issues.jboss.org/browse/JASSIST-226
> Project: Javassist
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.18.0-GA
> Environment: JavaSE-1.7, Eclipse Kepler
> Reporter: Paolo Paolo
> Assignee: Shigeru Chiba
> Labels: annotations
>
> I'm using Javassist to create .class file at runtime. Every method of the created class must have a Java Annotation ("@annotation example") with an URI. The problem is that the Annotation class modifies automatically the URI by substituting slashes with dots.
> //the Annotation String that I need
> @RDFBean('http://www.semanticweb.org/pi/2014/5/test#Test')
> //the resulting String
> @RDFBean('http:..www.semanticweb.org.pi.2014.5.test#Test')
> Is there a way to prevent this String modification?
> I suppose it's related to the different notation between a file path and a Java package.
> This is the code:
> ClassPool pool = ClassPool.getDefault();
> CtClass cc = pool.makeClass(className);
>
> ClassFile ccFile = cc.getClassFile();
> ConstPool constpool = ccFile.getConstPool();
> // create the annotation
> AnnotationsAttribute attr = new AnnotationsAttribute(constpool, AnnotationsAttribute.visibleTag);
> // classLocalName contains: http://www.semanticweb.org/pi/2014/5/test#Test
> Annotation annot = new Annotation("RDFBean('" + classLocalName + "')", constpool);
> attr.addAnnotation(annot);
> ccFile.addAttribute(attr);
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 2 months