July 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-3572) Deployment Overlay feature is not able to add jar files for resource adapter (rar) deployments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3572?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-3572: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1110635 > Deployment Overlay feature is not able to add jar files for resource adapter (rar) deployments > ---------------------------------------------------------------------------------------------- > > Key: WFLY-3572 > URL: https://issues.jboss.org/browse/WFLY-3572 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.1.0.Final > Reporter: Lyle Wang > Assignee: Jason Greene > Attachments: wmq.jmsra.rar > > > According to WFLY-1359[1], we should be able to add a jar for an existing deployment. > Testing against WildFly 8.1.0 Final, the deployment-overlay feature reports errors on adding a new .jar for a .rar resource adapter deployment. > [1] - https://issues.jboss.org/browse/WFLY-1359 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3572) Deployment Overlay feature is not able to add jar files for resource adapter (rar) deployments

by Lyle Wang (JIRA)

[ https://issues.jboss.org/browse/WFLY-3572?page=com.atlassian.jira.plugin.... ] Lyle Wang updated WFLY-3572: ---------------------------- Attachment: wmq.jmsra.rar > Deployment Overlay feature is not able to add jar files for resource adapter (rar) deployments > ---------------------------------------------------------------------------------------------- > > Key: WFLY-3572 > URL: https://issues.jboss.org/browse/WFLY-3572 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.1.0.Final > Reporter: Lyle Wang > Assignee: Jason Greene > Attachments: wmq.jmsra.rar > > > According to WFLY-1359[1], we should be able to add a jar for an existing deployment. > Testing against WildFly 8.1.0 Final, the deployment-overlay feature reports errors on adding a new .jar for a .rar resource adapter deployment. > [1] - https://issues.jboss.org/browse/WFLY-1359 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3572) Deployment Overlay feature is not able to add jar files for resource adapter (rar) deployments

by Lyle Wang (JIRA)

Lyle Wang created WFLY-3572: ------------------------------- Summary: Deployment Overlay feature is not able to add jar files for resource adapter (rar) deployments Key: WFLY-3572 URL: https://issues.jboss.org/browse/WFLY-3572 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: Server Affects Versions: 8.1.0.Final Reporter: Lyle Wang Assignee: Jason Greene According to WFLY-1359[1], we should be able to add a jar for an existing deployment. Testing against WildFly 8.1.0 Final, the deployment-overlay feature reports errors on adding a new .jar for a .rar resource adapter deployment. [1] - https://issues.jboss.org/browse/WFLY-1359 -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3227) Replace batching="true|false" with <transaction mode="BATCH"/> in infinispan subsystem schema/model

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3227?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-3227: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/6470 (was: https://github.com/wildfly/wildfly/pull/6469) > Replace batching="true|false" with <transaction mode="BATCH"/> in infinispan subsystem schema/model > --------------------------------------------------------------------------------------------------- > > Key: WFLY-3227 > URL: https://issues.jboss.org/browse/WFLY-3227 > Project: WildFly > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 9.0.0.CR1 > > > Currently, one enables use of Infinispan batching via the batching="true" attribute. The implications of batching have evolved over time, but currently batching uses the BatchModeTransactionManager, which makes it incompatible with a <transaction mode="..."/> other than NONE. > To resolve this mutual incompatibility and to remove any ambiguity, I propose replacing the batching attribute with a new transaction mode, i.e. <transaction mode="BATCH"/>. > The complete list of transaction modes would now be: > NONE: the cache is not configured with a transaction manager > BATCH: the cache is configured with a BatchModeTransactionManager > NON_XA: the cache is configured with WF's transaction manager, but will interact via Synchronizations > NON_DURABLE_XA: the cache is configured with WF's transaction manager and will interact via an XAResource w/out recovery. > FULL_XA: the cache is configured with WF's transaction manager and will interact via an XAResource w/recovery. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3540) Allow users to use web session clustering w/out batching

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-3540?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-3540: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/6470 (was: https://github.com/wildfly/wildfly/pull/6469) > Allow users to use web session clustering w/out batching > -------------------------------------------------------- > > Key: WFLY-3540 > URL: https://issues.jboss.org/browse/WFLY-3540 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.1.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 9.0.0.Alpha1 > > > The default web session clustering configuration is not particularly friendly to applications that make use of async requests, i.e. concurrent requests per session. To optimally support async access to the session, we really need to allow the user to disable batching and use auto-commit cache operations. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

9 years, 10 months

1
0
0 / 0

[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)

9 years, 10 months

1
0
0 / 0

[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)

9 years, 10 months

1
0
0 / 0

[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)

9 years, 10 months

1
0
0 / 0

[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)

9 years, 10 months

1
0
0 / 0

[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)

9 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2014