[JBoss JIRA] (WFLY-9788) EJB over HTTP fails with Arrays in Request
by Heiko Lettmann (JIRA)
[ https://issues.jboss.org/browse/WFLY-9788?page=com.atlassian.jira.plugin.... ]
Heiko Lettmann commented on WFLY-9788:
--------------------------------------
Hi Jaikiran. Thanks for your work. For the future I know how to communicate better. The bug is resolved as I can see by the testcase. I’m still trying to fix it for me but it’s probably because of the library that is used by the client. I’m new to maven but I will figure it out. EAP seems to be quite broken here. Will this be addressed, too?
> EJB over HTTP fails with Arrays in Request
> ------------------------------------------
>
> Key: WFLY-9788
> URL: https://issues.jboss.org/browse/WFLY-9788
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 11.0.0.Final
> Reporter: Heiko Lettmann
> Attachments: Test.zip
>
>
> I stumbled over the issue WFLY-9573. Then I updated to wildfly-http-client-1.0.9.Final which made a few invocations work. There I discovered another issue. I attached a modified Quickstart version to demonstrate it!
> Exception is on the client side:
> Exception in thread "main" javax.ejb.EJBException: java.io.IOException: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String
> at org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:128)
> at org.wildfly.httpclient.ejb.HttpInvocationHandler.lambda$handleInternal$0(HttpInvocationHandler.java:130)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.IOException: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String
> at org.wildfly.httpclient.ejb.HttpInvocationHandler$1.getRequestContent(HttpInvocationHandler.java:204)
> at org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:126)
> ... 4 more
> Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String
> at org.wildfly.httpclient.ejb.HttpInvocationHandler$1.getRequestContent(HttpInvocationHandler.java:178)
> ... 5 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-2719) Better use of the ManagementResourceRegistration data in JMX query handling
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2719?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2719:
-------------------------------------
Fix Version/s: 5.0.0.Alpha1
(was: 4.0.0.Beta2)
> Better use of the ManagementResourceRegistration data in JMX query handling
> ---------------------------------------------------------------------------
>
> Key: WFCORE-2719
> URL: https://issues.jboss.org/browse/WFCORE-2719
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management, JMX
> Reporter: Brian Stansberry
> Fix For: 5.0.0.Alpha1
>
>
> For MBeanServer.queryNames and queryMBeans calls with a property list pattern in the ObjectName param, look into using the MRR data to avoid searching parts of the tree where it's known that no resources can match.
> Imagine a query for {code}jboss.*:j2eetype=*,*{code} or, less extreme, {code}jboss.as:socket-binding=*,*{code}
> No resources at all will match the first query, and nothing outside the /socket-binding-group part of the tree will match the latter. But currently we search the entire tree, because those expressions can match resources at any level. (Remember, the key/value pairs in an ObjectName are not required to be in a particular order so we can't assume the order matches the order of key/value pairs in a PathAddress. So we'd have to look for any resource with an address with a PathElement at any position whose key is 'j2eetype' or 'socket-binding'.)
> Searching resources can be expensive, because resources are not necessarily simple configuration objects. They can also represent runtime-only objects, whose number and cost to access is dependent on the whatever the system being accessed does. OTOH, the MRR tree is completely under the kernel's control. So in these cases it may be more performant to use the MRR data to identify on those parts of the tree where a Resource search is necessary.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-482?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-482:
---------------------------------
Fix Version/s: 5.0.0.Alpha1
(was: 4.0.0.Beta2)
> Add log4j2 support for WildFly
> ------------------------------
>
> Key: WFCORE-482
> URL: https://issues.jboss.org/browse/WFCORE-482
> Project: WildFly Core
> Issue Type: Task
> Components: Logging
> Environment: Spring 3, Hibernate, Wicket, JBoss AS7
> Reporter: Amarkanth Ranganamayna
> Assignee: James Perkins
> Priority: Optional
> Fix For: 5.0.0.Alpha1
>
>
> I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2.
> Looks like Jboss AS7 by default use log4j 1.x
> Are you guys already working on using log4j2 ?
> If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging.
> Thanks,
> Amar
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3255) Complex type AttributeDefinition variants don't handle ParameterCorrector properly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3255?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3255:
-------------------------------------
Fix Version/s: 5.0.0.Alpha1
(was: 4.0.0.Beta2)
> Complex type AttributeDefinition variants don't handle ParameterCorrector properly
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-3255
> URL: https://issues.jboss.org/browse/WFCORE-3255
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 3.0.1.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 5.0.0.Alpha1
>
>
> If a field in a complex attribute (i.e. one that uses Object...AttributeDefinition) has a ParameterCorrector configured, that corrector never gets called. That's because only a corrector on the top level attribute gets called.
> These classes should automatically use an internal corrector that first calls any corrector configured for fields, and then, if one is present, calls any top level corrector.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months