[JBoss JIRA] (WFLY-3571) bad error message for invalid <resource-root path>
by Karl Pietrzak (JIRA)
[ https://issues.jboss.org/browse/WFLY-3571?page=com.atlassian.jira.plugin.... ]
Karl Pietrzak commented on WFLY-3571:
-------------------------------------
It might be related to WFLY-832 if the code is common.
> bad error message for invalid <resource-root path>
> --------------------------------------------------
>
> Key: WFLY-3571
> URL: https://issues.jboss.org/browse/WFLY-3571
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Karl Pietrzak
> Assignee: Jason Greene
> Priority: Minor
>
> h3. What
> If you have a typo in your path for your module.xml for a JDBC driver, e.g.,
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <module xmlns="urn:jboss:module:1.0" name="com.mysql">
> <resources>
> <resource-root path="DOES.NOT.EXIST.jar"/>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> </dependencies>
> </module>
> {code}
> WF just says:
> {noformat}
> 16:22:26,770 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 30) JBAS014613: Operation ("add") failed - address: ([
> ("subsystem" => "datasources"),
> ("jdbc-driver" => "com.mysql")
> {noformat}
> h3. Why
> This is not very informative, unfortunately. Maybe it's logged as level DEBUG instead of WARN? If someone points me to the name of the class that handles this kind of thing, I can submit a patch/pull request.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (WFLY-3571) bad error message for invalid <resource-root path>
by Karl Pietrzak (JIRA)
Karl Pietrzak created WFLY-3571:
-----------------------------------
Summary: bad error message for invalid <resource-root path>
Key: WFLY-3571
URL: https://issues.jboss.org/browse/WFLY-3571
Project: WildFly
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Reporter: Karl Pietrzak
Assignee: Jason Greene
Priority: Minor
h3. What
If you have a typo in your path for your module.xml for a JDBC driver, e.g.,
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="com.mysql">
<resources>
<resource-root path="DOES.NOT.EXIST.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
</dependencies>
</module>
{code}
WF just says:
{noformat}
16:22:26,770 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 30) JBAS014613: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("jdbc-driver" => "com.mysql")
{noformat}
h3. Why
This is not very informative, unfortunately. Maybe it's logged as level DEBUG instead of WARN? If someone points me to the name of the class that handles this kind of thing, I can submit a patch/pull request.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 months
[JBoss JIRA] (DROOLS-536) KieBuilder does not resolve declarations across packages
by Kevin Peterson (JIRA)
Kevin Peterson created DROOLS-536:
-------------------------------------
Summary: KieBuilder does not resolve declarations across packages
Key: DROOLS-536
URL: https://issues.jboss.org/browse/DROOLS-536
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.1.0.CR1, 6.0.1.Final
Reporter: Kevin Peterson
Assignee: Mark Proctor
Priority: Critical
Fix For: 6.1.0.Final
The KieBuilder loads the packages in the order declared in the kmodule.xml and builds them independently.
If a type declaration extends a second type declaration in another package, the latter may not have been processed yet, resulting in a compile-time exception.
Changing the order of the packages in the kmodule.xml does not help (and would prevent cross-dependencies)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 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 commented on WFLY-3560:
---------------------------------
[~swd847]
Is it possible to put a new version of Undertow to existing Wildfly final release by ourselves?
Thanks
> 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)
11 years, 10 months
[JBoss JIRA] (WFLY-3560) Combination of HTTP Request Header "Connection:keep-alive" and "Expect:100-conitnue" causes Wildfly undeploy apps
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-3560?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-3560:
--------------------------------------
It looks like this is an undertow issue, where it is attempting to send a 100-continue response even after the response has been commited, it has been fixed in Undertow upstream.
> 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)
11 years, 10 months
[JBoss JIRA] (WFLY-3495) /subsystem=transactions/log-store=log-store type attribute should be read-only
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3495?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3495:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1010847|https://bugzilla.redhat.com/show_bug.cgi?id=1010847] from MODIFIED to ON_QA
> /subsystem=transactions/log-store=log-store type attribute should be read-only
> ------------------------------------------------------------------------------
>
> Key: WFLY-3495
> URL: https://issues.jboss.org/browse/WFLY-3495
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Stefano Maestri
> Assignee: Jason Greene
> Fix For: 9.0.0.Alpha1
>
>
> There is non-standard behavior of log-store "address" in jboss-cli.
> If you want to change log store type via jboss-cli I suppose that supposed way is via command like:
> /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true)
> similarly with jdbc store.
> But there is a second way how to get name the transaction object store in use:
> /subsystem=transactions/log-store=log-store:read-attribute(name=type)
> But when you try to set the type via this way:
> /subsystem=transactions/log-store=log-store:write-attribute(name=type, value=hornetq)
> you'll get operation success
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> but no change in the model is realized.
> There should be some info to user that this way is not supported or this way should correctly work.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 10 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 edited comment on WFLY-3560 at 7/1/14 11:16 AM:
----------------------------------------------------------
I narrowed down the issue. It is not Connection:keep-alive related. It is POST + content body + Expect:100-continue issue.
These will cause Wildfly to throw exception:
curl -X POST -H Content-Type:text/plain -H Expect:100-continue -d 'test' http://localhost:8080/
curl -X POST -H Content-Type:application/json -H Expect:100-continue -d '"name":"joe"' http://localhost:8080/
These will not:
curl -X POST -H Content-Type:text/plain -H Expect:100-continue http://localhost:8080/
curl -X POST -H Expect:100-continue -d 'test' http://localhost:8080/
curl -X POST -H Expect:100-continue http://localhost:8080/
Don't see the problem with PUT actions.
was (Author: gyang2):
I narrowed down the issue. It is not Connection:keep-alive related. It is POST + content body + Expect:100=continue issue.
These will cause Wildfly to throw exception:
curl -X POST -H Content-Type:text/plain -H Expect:100-continue -d 'test' http://localhost:8080/
curl -X POST -H Content-Type:application/json -H Expect:100-continue -d '"name":"joe"' http://localhost:8080/
These will not:
curl -X POST -H Content-Type:text/plain -H Expect:100-continue http://localhost:8080/
curl -X POST -H Expect:100-continue -d 'test' http://localhost:8080/
curl -X POST -H Expect:100-continue http://localhost:8080/
Don't see the problem with PUT actions.
> 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)
11 years, 10 months