[JBoss JIRA] (WFLY-8907) ClassCastException due to wrong class loader after remote EJB invocation inside the same JVM
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-8907:
---------------------------------
Summary: ClassCastException due to wrong class loader after remote EJB invocation inside the same JVM
Key: WFLY-8907
URL: https://issues.jboss.org/browse/WFLY-8907
Project: WildFly
Issue Type: Bug
Components: EJB, Remoting
Reporter: Tomaz Cerar
Assignee: David Lloyd
Attachments: projects.zip, wildfly.patch.txt
reported on github https://github.com/wildfly/wildfly/issues/9990
by https://github.com/strohmattenverleger
Hello,
I think I've discovered a bug in WildFly 10.1 regarding remote EJB invocations inside the same JVM.
When the caller uses an interface for a remote invocation which is part of a JBoss module instead of the calling Java EE module, WildFly tries to clone the entire return value object graph using the interface's JBoss module class loader instead of the Java EE module's class loader.
I've attached three Maven projects which reproduce the issue. To reproduce the issue just build the projects, deploy them (don't forget the JBoss module generic-service-api which you can find pre-built inside the project's target directory), run your WildFly and open http://localhost:8080/b-service-war/my-entities/42 in a browser. You should get a ClassCastException.
I've also attached a patch which contains a fix. It actually contains two fixes:
Using the Java EE module's class loader instead of the interface's JBoss module class loader
Getting rid of the LocalInvocationClassCloner, because it has no upside, but a downside which is swallowing/hiding packaging issue
If you accept this issue, I'd be willing to commit a fix and create a pull request for you.
Regards
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (WFCORE-2930) Support a socket-binding-group as a child of profile
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2930:
----------------------------------------
Summary: Support a socket-binding-group as a child of profile
Key: WFCORE-2930
URL: https://issues.jboss.org/browse/WFCORE-2930
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Critical
Fix For: 4.0.0.Beta1
Allow a single socket-binding-group resource as a child of profile, such that resolution of bindings from the subsystems are limited to the s-b-g associated with the profile.
A server-group that uses such a profile cannot reference a socket-binding-group. And a server in that server-group cannot reference an s-b-g to override the one from the server-group/profile.
I'm not sure how the s-b-g resource will work. Perhaps the resource would go away under 'profile' with the bindings direct children of profile. The 'default-interface' attribute then becomes an attribute of profile. Or perhaps there will be an s-b-g resource, but with a fixed name that's the same as the profile. Currently I think the latter.
This will be necessary for resolution of config elements using the upcoming provisioning tool. The tool will not be able to do correct "feature" resolution using the complex rules we currently support.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month
[JBoss JIRA] (DROOLS-1609) Augment FEEL AST node at compilation with return type
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-1609:
--------------------------------------
Summary: Augment FEEL AST node at compilation with return type
Key: DROOLS-1609
URL: https://issues.jboss.org/browse/DROOLS-1609
Project: Drools
Issue Type: Enhancement
Components: dmn engine
Reporter: Matteo Mortari
Assignee: Matteo Mortari
This is needed so to be able to determine the result of a boxed function at compile time, in turn to be able at compile time to determine a valid compilation without error of a BKM for instance.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 1 month