[JBoss JIRA] (WFLY-11600) org.jboss.invocation.CannotProceedException cannot be unmarshalled by the wildfly client
by Bartosz Baranowski (Jira)
[ https://issues.jboss.org/browse/WFLY-11600?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski commented on WFLY-11600:
-------------------------------------------
Could we get a reproducer?
> org.jboss.invocation.CannotProceedException cannot be unmarshalled by the wildfly client
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-11600
> URL: https://issues.jboss.org/browse/WFLY-11600
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.1.0.Final
> Reporter: Vladimir Kravchenko
> Assignee: Brian Stansberry
> Priority: Major
>
> The org.jboss.invocation.CannotProceedException either must not be propagated to a client or it must be included in one of wildfly-ejb-client-bom transient dependencies. Otherwise the client fails to unmarshal it:
> {noformat}
> javax.ejb.EJBException: 'java.lang.ClassNotFoundException: org.jboss.invocation.CannotProceedException'
> Stacktrace :
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:238)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy48.waitForTypedMessagingProcess(Unknown Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> ... 43 more
> Trigger list :
> 1. java.lang.ClassNotFoundException: 'org.jboss.invocation.CannotProceedException'
> Stacktrace :
> at java.lang.ClassLoader.findClass(ClassLoader.java:530)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> ...
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:131)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:112)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:948)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1255)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverObjectInputStream.defaultReadObject(RiverObjectInputStream.java:81)
> at java.lang.Throwable.readObject(Throwable.java:914)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:309)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1637)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:79)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:276)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:142)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> ... 50 more
> {noformat}
> I got this exception with WildFly 10.1.0.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-8643) RestEasy GZIP Compression Not Setting Content-Encoding
by Marek Kopecký (Jira)
[ https://issues.jboss.org/browse/WFLY-8643?page=com.atlassian.jira.plugin.... ]
Marek Kopecký commented on WFLY-8643:
-------------------------------------
[~xhammond]: I'm not able to reproduce this issue on WF15:
# ./standalone.sh -Dresteasy.allowGzip=true
# Deploy application with {code:java}
@Path("/")
public class Resource {
@GET
@Path("/a")
@GZIP
public String a(@QueryParam("a") String a) {
return a;
}
}
{code}
# {noformat}[mkopecky@dhcp-10-40-5-71 single-application] (master *+)$ curl -H "Accept-Encoding: gzip, deflate" -v -X GET http://localhost:8080/jaxrs-wf/a?a=a
...
> GET /jaxrs-wf/a?a=a HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.55.1
> Accept: */*
> Accept-Encoding: gzip, deflate
>
< HTTP/1.1 200 OK
< Content-Encoding: gzip
< Connection: keep-alive
< Content-Type: application/octet-stream
< Content-Length: 21
< Date: Wed, 16 Jan 2019 11:31:38 GMT
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failed writing body (0 != 21)
* stopped the pause stream!
* Closing connection 0
[mkopecky@dhcp-10-40-5-71 single-application] (master *+)$ {noformat}
[~baranowb] (cc [~asoldano], [~pmackay]): Can you close this issue as out-of-date? If [~xhammond] still see this issue, he can reopen this issue with a reproducer (for example zip archive with simple maven project and steps to reproduce).
> RestEasy GZIP Compression Not Setting Content-Encoding
> ------------------------------------------------------
>
> Key: WFLY-8643
> URL: https://issues.jboss.org/browse/WFLY-8643
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 11.0.0.Alpha1
> Environment: Encountered the issue running in a Windows 7 environment
> Reporter: Xavier Hammond
> Assignee: Bartosz Baranowski
> Priority: Major
>
> The Content-Encoding is not set to gzip when a RESTful service endpoint returns GZIP compressed data.
> This only occurs when I deploy to the Wildfly 11 Alpha release. No issues with Wildfly 10 Final.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3526) [DMN Designer] Add support for padding Node labels from set positions
by Michael Anstis (Jira)
Michael Anstis created DROOLS-3526:
--------------------------------------
Summary: [DMN Designer] Add support for padding Node labels from set positions
Key: DROOLS-3526
URL: https://issues.jboss.org/browse/DROOLS-3526
Project: Drools
Issue Type: Feature Request
Components: DMN Editor
Affects Versions: 7.16.0.Final
Reporter: Michael Anstis
Assignee: Michael Anstis
Attachments: DROOLS-3526.png
The "Decision Service" node has it's label at {{HasTitle.Position.TOP}} however this is taken quite literally and the text often is overlapped by the node's border. We need to add support for _padding_ the {{TOP}} position slightly.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11601) Weld vs Undertow bootstrap: Race condition
by Ste Gr (Jira)
[ https://issues.jboss.org/browse/WFLY-11601?page=com.atlassian.jira.plugin... ]
Ste Gr updated WFLY-11601:
--------------------------
Description:
WFLY-9732 / WFLY-10784 moves the completion of WELD from the WeldStartService to WeldStartCompetionService. This causes a race condition with the UndertowDeploymentService which executes the servlet listeners for context-initialized which again fires ApplicationScope-initialized events in CDI.
You can find more in [WELD-2557|https://issues.jboss.org/browse/WELD-2557?focusedCommentId=1368...].
In short: WeldStartCompletionService and UndertowDeploymentService pushes the logic to the executor service. It may happen, that the logik of undertow runs before the weld completion. Events fired in the servlet listeners won't find all event observers.
A possible solution would bo to set the WeldStartCompletionService as a dependency of the UndertowDeploymentService
was:
WFLY-9732 moves the completion of WELD from the WeldStartService to WeldStartCompetionService. This causes a race condition with the UndertowDeploymentService which executes the servlet listeners for context-initialized which again fires ApplicationScope-initialized events in CDI.
You can find more in [WELD-2557|https://issues.jboss.org/browse/WELD-2557?focusedCommentId=1368...].
In short: WeldStartCompletionService and UndertowDeploymentService pushes the logic to the executor service. It may happen, that the logik of undertow runs before the weld completion. Events fired in the servlet listeners won't find all event observers.
A possible solution would bo to set the WeldStartCompletionService as a dependency of the UndertowDeploymentService
> Weld vs Undertow bootstrap: Race condition
> ------------------------------------------
>
> Key: WFLY-11601
> URL: https://issues.jboss.org/browse/WFLY-11601
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Web (Undertow)
> Affects Versions: 15.0.1.Final
> Reporter: Ste Gr
> Assignee: Matej Novotny
> Priority: Major
>
> WFLY-9732 / WFLY-10784 moves the completion of WELD from the WeldStartService to WeldStartCompetionService. This causes a race condition with the UndertowDeploymentService which executes the servlet listeners for context-initialized which again fires ApplicationScope-initialized events in CDI.
> You can find more in [WELD-2557|https://issues.jboss.org/browse/WELD-2557?focusedCommentId=1368...].
> In short: WeldStartCompletionService and UndertowDeploymentService pushes the logic to the executor service. It may happen, that the logik of undertow runs before the weld completion. Events fired in the servlet listeners won't find all event observers.
> A possible solution would bo to set the WeldStartCompletionService as a dependency of the UndertowDeploymentService
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3517) [DMN Designer] Data Types - Constraints - Constraint property
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-3517?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-3517:
----------------------------------------
[~karreiro] One for [~tirelli]... should we add our own attribute to `ItemDefinition` or re-use an _existing vendors extension_ (w/o being too explicit)?
For example "none", "simple" (being our _range_), "expression" and "enumeration".
> [DMN Designer] Data Types - Constraints - Constraint property
> -------------------------------------------------------------
>
> Key: DROOLS-3517
> URL: https://issues.jboss.org/browse/DROOLS-3517
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Guilherme Carreiro
> Assignee: Daniel José dos Santos
> Priority: Major
> Labels: drools-tools
>
> Currently the _Constraint dialog_ infers the {{Constraint type}} based on the value.
> - A new property ({{kie:constraintType}}) needs to be added in the in {{itemDefinition.allowedValues}} element. See how the DMN file will look like:
> {noformat}
> <?xml version="1.0" ?>
> <dmn:definitions ...>
> <dmn:itemDefinition id="_C9B6988F-0302" name="tNum" isCollection="false">
> <dmn:typeRef>number</dmn:typeRef>
> <dmn:allowedValues kie:constraintType="range" id="_F7A1878D-A464">
> <dmn:text>(1..200)</dmn:text>
> </dmn:allowedValues>
> </dmn:itemDefinition>
> <dmndi:DMNDI>
> <dmndi:DMNDiagram></dmndi:DMNDiagram>
> </dmndi:DMNDI>
> </dmn:definitions>
> {noformat}
> - Update the {{DataType}} class with the new property (from {{ItemDefinition.allowedValues}});
> - Use the new property in the {{DataTypeConstraintModal}} class to load the right component (instead of inferring the type).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11601) Weld vs Undertow bootstrap: Race condition
by Ste Gr (Jira)
Ste Gr created WFLY-11601:
-----------------------------
Summary: Weld vs Undertow bootstrap: Race condition
Key: WFLY-11601
URL: https://issues.jboss.org/browse/WFLY-11601
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, Web (Undertow)
Affects Versions: 15.0.1.Final
Reporter: Ste Gr
Assignee: Matej Novotny
WFLY-9732 moves the completion of WELD from the WeldStartService to WeldStartCompetionService. This causes a race condition with the UndertowDeploymentService which executes the servlet listeners for context-initialized which again fires ApplicationScope-initialized events in CDI.
You can find more in [WELD-2557|https://issues.jboss.org/browse/WELD-2557?focusedCommentId=1368...].
In short: WeldStartCompletionService and UndertowDeploymentService pushes the logic to the executor service. It may happen, that the logik of undertow runs before the weld completion. Events fired in the servlet listeners won't find all event observers.
A possible solution would bo to set the WeldStartCompletionService as a dependency of the UndertowDeploymentService
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11600) org.jboss.invocation.CannotProceedException cannot be unmarshalled by the wildfly client
by Vladimir Kravchenko (Jira)
Vladimir Kravchenko created WFLY-11600:
------------------------------------------
Summary: org.jboss.invocation.CannotProceedException cannot be unmarshalled by the wildfly client
Key: WFLY-11600
URL: https://issues.jboss.org/browse/WFLY-11600
Project: WildFly
Issue Type: Bug
Affects Versions: 10.1.0.Final
Reporter: Vladimir Kravchenko
Assignee: Brian Stansberry
The org.jboss.invocation.CannotProceedException either must not be propagated to a client or it must be included in one of wildfly-ejb-client-bom transient dependencies. Otherwise the client fails to unmarshal it:
{noformat}
javax.ejb.EJBException: 'java.lang.ClassNotFoundException: org.jboss.invocation.CannotProceedException'
Stacktrace :
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:238)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
at com.sun.proxy.$Proxy48.waitForTypedMessagingProcess(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
... 43 more
Trigger list :
1. java.lang.ClassNotFoundException: 'org.jboss.invocation.CannotProceedException'
Stacktrace :
at java.lang.ClassLoader.findClass(ClassLoader.java:530)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
...
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:131)
at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:112)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:948)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1255)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
at org.jboss.marshalling.river.RiverObjectInputStream.defaultReadObject(RiverObjectInputStream.java:81)
at java.lang.Throwable.readObject(Throwable.java:914)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:309)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1637)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:79)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:276)
at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:142)
at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
... 50 more
{noformat}
I got this exception with WildFly 10.1.0.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months