[JBoss JIRA] (WFLY-1105) PU Injection across JARs (separate DeploymentUnits)
by Brad Maxwell (JIRA)
[ https://issues.jboss.org/browse/WFLY-1105?page=com.atlassian.jira.plugin.... ]
Brad Maxwell commented on WFLY-1105:
------------------------------------
I suppose it worked before because the persistence unit was being deployed into the unified classloader. In Wildlfy all deployments are in their own classloader.
The JavaEE specs define things in terms of deployments and deployments should have everything they require packaged.
As far as shaing a PersistenceUnit / EntityManager across deployments, it can be done by specifying the 'jboss.entity.manager.jndi.name' Hibernate property in the persistence.xml. This will bind the EntityManager in JNDI.
<persistence-unit name="shared-jpa" transaction-type="JTA">
...
<properties>
...
<property name="jboss.entity.manager.jndi.name" value="java:shared/HelloWorldEntityManager"/>
<property name="jboss.entity.manager.factory.jndi.name" value="java:shared/HelloWorldEntityManagerFactory"/>
</properties>
</persistence-unit>
The deploy the jar containing the JPA Entities and persistence.xml.
Then any other deployment that needs the Persistence unit would declare a classloading dependency on the persistence jar deployment via jboss-deployment-structure.xml
Then just inject the EntityManager or look it up such as:
@Resource(lookup="java:shared/HelloWorldEntityManager")
private EntityManager entityManager;
> PU Injection across JARs (separate DeploymentUnits)
> ---------------------------------------------------
>
> Key: WFLY-1105
> URL: https://issues.jboss.org/browse/WFLY-1105
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Environment: Linux, Window, MacOS, *BSD
> Reporter: Nikos Ballas
> Labels: new_and_noteworthy
>
> the following architecture of jars/wars doesn't load correctly in JBossAS 7 but it was used to load perfectly in all previous versions...i know about the new loading way so i am explaining the scenario:
>
> myjar-model.jar : Contains entities and the persistence.xml which defines also a persistence unit inside the META-INF folder.
> myjar-buisness.jar: Contains EJB's and Spring beans that uses the model.There is an annotation with @PersistenceContext(name="mypu") on this EJB's for the entity manager to work. The jboss-deployment-structure.xml has declared dependency in the deployment.mcube-model.jar.
> I am copying both of these files first the model and then the buisness in the standalone profile in deployments folder.The first one is loaded successfully.The second one that also uses classes from the previous one can see the classes but not the pu need it for the db operations.The exception follows:
> [code]
> 10:33:49,369 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC00001: Failed to start service jboss.deployment.unit."myjar-buisness.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."mcube-buisness.jar".INSTALL: Failed to process phase INSTALL of deployment "myjar-buisness.jar"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1765)
> at org.jboss.msc.service.ServiceControllerImpl$ClearTCCLTask.run(ServiceControllerImpl.java:2291)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
> at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Component class ***.**.GenericDAOImpl for component MyBean has errors:
> Can't find a deployment unit named myjar-persistence at deployment "myjar-buisness.jar"
> at org.jboss.as.ee.component.ModuleJndiBindingProcessor$1.handle(ModuleJndiBindingProcessor.java:133)
> at org.jboss.as.ee.component.ClassDescriptionTraversal.run(ClassDescriptionTraversal.java:52)
> at org.jboss.as.ee.component.ModuleJndiBindingProcessor.processClassConfigurations(ModuleJndiBindingProcessor.java:129)
> at org.jboss.as.ee.component.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:122)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115)
> ... 5 more
> [/code]
> Following scenario/arcs:
> Web application which is assembled by 4 different jars/wars:
> (1)myapp-model.jar -> contains the model + persistence.xml containing the definition of a CMT.
> (2)myapp-buisness.jar -> contains buisness EJB3's Spring Beans, whatever you can think of.
> (3)myapp-messaging.jar -> Contains MDB's for sending messages to several queues.
> (4)myapp-console.war -> Contains the web interface of the app.
> Now the -> define a dependency from a project to another to function,i.e. A->B means that A project has a dependency in B. Now the graph of dependencies between projects are:
> (4)->(2)->(1).
> Currently in jboss as 7 you are able to deploy your application either as module exposing several services(even though there is no clear documentation on how you do that.You follow the old way, you have to do something else?Nowhere in any documentation isn't that documented.) or you can use the deployments folder and copy everything there.Given the previous scenario if we deploy the module(2) then even if we have as dependency in the jboss-deployment-structure.xml the reference to the module(1) then we will get an exception saying that the persistence unit defined isn't accessible or undefined for the module(2). Now with the new version of jboss that allow us to manipulate the dependencies using the module mechanism and the well defined deployment and dependencies between projects it would be really useful if.
> When we define a dependency from one module to another, in my example from (2)->(1), also the mcs services defined are also exported in the target deployment, thus allowing access to the pu with the name for example is deployed. I don't know if this can be applied for the module architecture also.
> regards
> Nick
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (ELY-85) Support GSS-Proxy
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-85:
-----------------------------------
Summary: Support GSS-Proxy
Key: ELY-85
URL: https://issues.jboss.org/browse/ELY-85
Project: WildFly Elytron
Issue Type: Feature Request
Components: SASL
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.0.0.Beta1
GSS Proxy is something we should consider being able to support when running on an OS that supports it: -
https://fedorahosted.org/gss-proxy/
The big first step will be to identify what is required to achieve this, is this something that can be solved with a custom login module or does this also impact on the Java supplied GSSAPI implementation.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3884) Integrate mod_cluster subsystem with security subsystem for SSL configuration
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-3884:
----------------------------------
Summary: Integrate mod_cluster subsystem with security subsystem for SSL configuration
Key: WFLY-3884
URL: https://issues.jboss.org/browse/WFLY-3884
Project: WildFly
Issue Type: Feature Request
Components: Clustering
Affects Versions: 9.0.0.Alpha1
Reporter: Paul Ferraro
Assignee: Radoslav Husar
Currently, the SSL certificate configuration is embedded within the mod_cluster subsystem configuration. Ideally, mod_cluster would reference this configuration from the security subsystem.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFCORE-99) standalone.bat script does not parse JAVA_OPTS containing '|' symbol properly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-99?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFCORE-99:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1145185
> standalone.bat script does not parse JAVA_OPTS containing '|' symbol properly
> -----------------------------------------------------------------------------
>
> Key: WFCORE-99
> URL: https://issues.jboss.org/browse/WFCORE-99
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 1.0.0.Alpha6
> Environment: Windows OS
> Reporter: Jay Kumar SenSharma
> Assignee: Tomaz Cerar
>
> *Scenario -1*
> - With the following line of JAVA_OPTS in "standalone.bat.conf" file
> {code}
> set "JAVA_OPTS=%JAVA_OPTS% -Dhttp.nonProxyHosts=localhost|127.0.0.1|10.10.10.*"
> {code}
> Error while starting WildFly
> {code}
> C:\wildfly-9.0.0.Alpha1-SNAPSHOT\bin>standalone.bat
> Calling "C:\wildfly-9.0.0.Alpha1-SNAPSHOT\bin\standalone.conf.bat"
> Setting JAVA property to "C:\JDKs\jdk1.7.0_67\bin\java"
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> {code}
> *Scenario -2*
> - In Windows "^" sign is the escape character so we tried altering the JAVA_OPTS as following in the "standalone.bat.conf" file:
> {code}
> set "JAVA_OPTS=%JAVA_OPTS% -Dhttp.nonProxyHosts=localhost^|127.0.0.1^|10.10.10.*"
> {code}
> Now WildFly server starts but still we see the following messages in windows console:
> {code}
> C:\wildfly-9.0.0.Alpha1-SNAPSHOT\bin>standalone.bat
> Calling "C:\wildfly-9.0.0.Alpha1-SNAPSHOT\bin\standalone.conf.bat"
> Setting JAVA property to "C:\JDKs\jdk1.7.0_67\bin\java"
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> ===============================================================================
> JBoss Bootstrap Environment
> JBOSS_HOME: "C:\wildfly-9.0.0.Alpha1-SNAPSHOT"
> JAVA: "C:\JDKs\jdk1.7.0_67\bin\java"
> JAVA_OPTS: "-client -Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MaxPermSize=256M -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=
> org.jboss.byteman -Dhttp.nonProxyHosts=localhost^|127.0.0.1^|10.10.10.*"
> ===============================================================================
> 15:50:35,453 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.4.Final
> 15:50:35,781 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.2.Final
> 15:50:35,953 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly 1.0.0.Alpha5 "Kenny" starting
> {code}
> *NOTE*: It is also not possible to pass such JAVA_OPTS via command line, because it causes the same error:
> {code}
> C:\wildfly-9.0.0.Alpha1-SNAPSHOT\bin>standalone.bat -Dhttp.nonProxyHosts=localhost|127.0.0.1|10.10.10.*
> '127.0.0.1' is not recognized as an internal or external command,
> operable program or batch file.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[JBoss JIRA] (WFLY-3429) Classloader leak in JBossCachedAuthenticationManager
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3429?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3429:
-----------------------------------------------
Josef Cacek <jcacek(a)redhat.com> changed the Status of [bug 1103735|https://bugzilla.redhat.com/show_bug.cgi?id=1103735] from ON_QA to ASSIGNED
> Classloader leak in JBossCachedAuthenticationManager
> ----------------------------------------------------
>
> Key: WFLY-3429
> URL: https://issues.jboss.org/browse/WFLY-3429
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.1.0.Final
> Reporter: Josef Cacek
> Assignee: Emmanuel Hugonnet
> Priority: Critical
>
> When using a security domain with {{cache-type="default"}}, then the ModuleClassLoader instances related to deployments leak through JBossCachedAuthenticationManager.
> The problematic piece of code is the domainCache member variable which in the DomainInfo value holds a LoginContext instance. This LoginContext has member contextClassLoader which causes the leak. (It points to the ModuleClassLoader of the deployment).
> One option to solve this issue could be to remove the cache entries which are related to the undeployed application.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 1 month
[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 9/22/14 9:30 AM:
----------------------------------------------------------
Unfortunately the problem has not been fixed in 9.0.0.Alpha1:
{noformat}
09:17:49,002 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 51) WFLYUT0014: Creating file handler for path /Users/gyang/Downloads/wildfly-9.0.0.Alpha1/welcome-content
09:17:49,039 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0012: Started server default-server.
09:17:49,059 INFO [org.wildfly.extension.undertow] (MSC service thread 1-11) WFLYUT0018: Host default-host starting
09:17:49,128 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8082
09:17:49,274 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-10) WFLYDS0013: Started FileSystemDeploymentService for directory /Users/gyang/Downloads/wildfly-9.0.0.Alpha1/standalone/deployments
09:17:49,280 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
09:17:49,445 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.0.0.Beta1
09:17:49,536 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
09:17:49,537 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
09:17:49,537 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 9.0.0.Alpha1 (WildFly Core 1.0.0.Alpha8) started in 2471ms - Started 193 of 295 services (135 services are lazy, passive or on-demand)
09:17:55,980 ERROR [stderr] (default task-1) Exception in thread "default task-1" java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
09:17:55,981 ERROR [stderr] (default task-1) at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:96)
09:17:55,981 ERROR [stderr] (default task-1) at io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.transferTo(HttpContinueReadHandler.java:84)
09:17:55,981 ERROR [stderr] (default task-1) at org.xnio.conduits.ConduitStreamSourceChannel.transferTo(ConduitStreamSourceChannel.java:83)
09:17:55,981 ERROR [stderr] (default task-1) at io.undertow.channels.DetachableStreamSourceChannel.transferTo(DetachableStreamSourceChannel.java:68)
09:17:55,982 ERROR [stderr] (default task-1) at io.undertow.server.HttpServerExchange$ReadDispatchChannel.transferTo(HttpServerExchange.java:1850)
09:17:55,982 ERROR [stderr] (default task-1) at org.xnio.channels.Channels.drain(Channels.java:807)
09:17:55,982 ERROR [stderr] (default task-1) at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1441)
09:17:55,982 ERROR [stderr] (default task-1) at io.undertow.io.DefaultIoCallback$1.onComplete(DefaultIoCallback.java:44)
09:17:55,983 ERROR [stderr] (default task-1) at io.undertow.io.AsyncSenderImpl.close(AsyncSenderImpl.java:347)
09:17:55,983 ERROR [stderr] (default task-1) at io.undertow.io.DefaultIoCallback.onComplete(DefaultIoCallback.java:41)
09:17:55,983 ERROR [stderr] (default task-1) at io.undertow.server.handlers.resource.FileResource$1ServerTask.run(FileResource.java:155)
09:17:55,983 ERROR [stderr] (default task-1) at io.undertow.server.handlers.resource.FileResource$1ServerTask.onComplete(FileResource.java:172)
09:17:55,984 ERROR [stderr] (default task-1) at io.undertow.io.AsyncSenderImpl.invokeOnComplete(AsyncSenderImpl.java:380)
09:17:55,984 ERROR [stderr] (default task-1) at io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:175)
09:17:55,984 ERROR [stderr] (default task-1) at io.undertow.server.handlers.resource.FileResource$1ServerTask.run(FileResource.java:159)
09:17:55,984 ERROR [stderr] (default task-1) at io.undertow.server.handlers.resource.FileResource.serve(FileResource.java:224)
09:17:55,985 ERROR [stderr] (default task-1) at io.undertow.server.handlers.resource.ResourceHandler$1.run(ResourceHandler.java:256)
09:17:55,985 ERROR [stderr] (default task-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
09:17:55,985 ERROR [stderr] (default task-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
09:17:55,985 ERROR [stderr] (default task-1) at java.lang.Thread.run(Thread.java:745)
{noformat}
was (Author: gyang2):
Unfortunately the problem has not been fixed in 9.0.0.Alpha1:
09:17:49,002 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 51) WFLYUT0014: Creating file handler for path /Users/gyang/Downloads/wildfly-9.0.0.Alpha1/welcome-content
09:17:49,039 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0012: Started server default-server.
09:17:49,059 INFO [org.wildfly.extension.undertow] (MSC service thread 1-11) WFLYUT0018: Host default-host starting
09:17:49,128 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0006: Undertow HTTP listener default listening on /127.0.0.1:8082
09:17:49,274 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-10) WFLYDS0013: Started FileSystemDeploymentService for directory /Users/gyang/Downloads/wildfly-9.0.0.Alpha1/standalone/deployments
09:17:49,280 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) WFLYJCA0001: Bound data source [java:jboss/datasources/ExampleDS]
09:17:49,445 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBoss Web Services - Stack CXF Server 5.0.0.Beta1
09:17:49,536 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
09:17:49,537 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
09:17:49,537 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 9.0.0.Alpha1 (WildFly Core 1.0.0.Alpha8) started in 2471ms - Started 193 of 295 services (135 services are lazy, passive or on-demand)
09:17:55,980 ERROR [stderr] (default task-1) Exception in thread "default task-1" java.lang.IllegalStateException: UT000004: getResponseChannel() has already been called
09:17:55,981 ERROR [stderr] (default task-1) at io.undertow.server.protocol.http.HttpContinue.createResponseSender(HttpContinue.java:96)
09:17:55,981 ERROR [stderr] (default task-1) at io.undertow.server.handlers.HttpContinueReadHandler$ContinueConduit.transferTo(HttpContinueReadHandler.java:84)
09:17:55,981 ERROR [stderr] (default task-1) at org.xnio.conduits.ConduitStreamSourceChannel.transferTo(ConduitStreamSourceChannel.java:83)
09:17:55,981 ERROR [stderr] (default task-1) at io.undertow.channels.DetachableStreamSourceChannel.transferTo(DetachableStreamSourceChannel.java:68)
09:17:55,982 ERROR [stderr] (default task-1) at io.undertow.server.HttpServerExchange$ReadDispatchChannel.transferTo(HttpServerExchange.java:1850)
09:17:55,982 ERROR [stderr] (default task-1) at org.xnio.channels.Channels.drain(Channels.java:807)
09:17:55,982 ERROR [stderr] (default task-1) at io.undertow.server.HttpServerExchange.endExchange(HttpServerExchange.java:1441)
09:17:55,982 ERROR [stderr] (default task-1) at io.undertow.io.DefaultIoCallback$1.onComplete(DefaultIoCallback.java:44)
09:17:55,983 ERROR [stderr] (default task-1) at io.undertow.io.AsyncSenderImpl.close(AsyncSenderImpl.java:347)
09:17:55,983 ERROR [stderr] (default task-1) at io.undertow.io.DefaultIoCallback.onComplete(DefaultIoCallback.java:41)
09:17:55,983 ERROR [stderr] (default task-1) at io.undertow.server.handlers.resource.FileResource$1ServerTask.run(FileResource.java:155)
09:17:55,983 ERROR [stderr] (default task-1) at io.undertow.server.handlers.resource.FileResource$1ServerTask.onComplete(FileResource.java:172)
09:17:55,984 ERROR [stderr] (default task-1) at io.undertow.io.AsyncSenderImpl.invokeOnComplete(AsyncSenderImpl.java:380)
09:17:55,984 ERROR [stderr] (default task-1) at io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:175)
09:17:55,984 ERROR [stderr] (default task-1) at io.undertow.server.handlers.resource.FileResource$1ServerTask.run(FileResource.java:159)
09:17:55,984 ERROR [stderr] (default task-1) at io.undertow.server.handlers.resource.FileResource.serve(FileResource.java:224)
09:17:55,985 ERROR [stderr] (default task-1) at io.undertow.server.handlers.resource.ResourceHandler$1.run(ResourceHandler.java:256)
09:17:55,985 ERROR [stderr] (default task-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
09:17:55,985 ERROR [stderr] (default task-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
09:17:55,985 ERROR [stderr] (default task-1) at java.lang.Thread.run(Thread.java:745)
> 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
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final, 8.1.0.Final, 9.0.0.Alpha1
> Reporter: Gary Yang
> Assignee: Stuart Douglas
>
> 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.3.1#6329)
10 years, 1 month
[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 reassigned WFLY-3560:
---------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
> 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
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final, 8.1.0.Final, 9.0.0.Alpha1
> Reporter: Gary Yang
> Assignee: Stuart Douglas
>
> 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.3.1#6329)
10 years, 1 month
[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: 9.0.0.Alpha1
> 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
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Final, 8.1.0.Final, 9.0.0.Alpha1
> 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.3.1#6329)
10 years, 1 month