March 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-838) Can't get implementing classname for JSR77 MBean

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-838?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated WFLY-838: ---------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/6578 (was: https://github.com/wildfly/wildfly/pull/6545) > Can't get implementing classname for JSR77 MBean > ------------------------------------------------ > > Key: WFLY-838 > URL: https://issues.jboss.org/browse/WFLY-838 > Project: WildFly > Issue Type: Bug > Components: JMX > Reporter: Anders Welen > Priority: Minor > Fix For: Awaiting Volunteers > > > The following exception are thrown when asking the MBean server for the classname implementing "jboss.jsr77:j2eeType=WebModule,name=MyWar.war,J2EEServer=default". > It should be a legal call. Why are the code clearly states it's illegal? > > java.lang.IllegalStateException: JBAS019905: Should not get called > at org.jboss.as.jsr77.managedobject.J2EEDeployedObjectHandlers$J2EEModuleHandler.queryObjectNames(J2EEDeployedObjectHandlers.java:245) > at org.jboss.as.jsr77.managedobject.BaseHandler.getMBeanInfo(BaseHandler.java:64) > at org.jboss.as.jsr77.managedobject.J2EEDeployedObjectHandlers.getMBeanInfo(J2EEDeployedObjectHandlers.java:147) > at org.jboss.as.jsr77.managedobject.ManagedObjectHandlerRegistry.getMBeanInfo(ManagedObjectHandlerRegistry.java:112) > at org.jboss.as.jsr77.subsystem.JSR77ManagementMBeanServer.getMBeanInfo(JSR77ManagementMBeanServer.java:179) > at org.jboss.as.jmx.PluggableMBeanServerImpl.getMBeanInfo(PluggableMBeanServerImpl.java:212) > > The error can easily be triggered by using JConsole to browse the same MBean. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-577) Where a complex attribute contains a Object type that contains an ObjectList the value type of the ObjectList is not returned in the resource description.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-577?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFCORE-577: ------------------------------------ Labels: affects_elytron (was: ) > Where a complex attribute contains a Object type that contains an ObjectList the value type of the ObjectList is not returned in the resource description. > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-577 > URL: https://issues.jboss.org/browse/WFCORE-577 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Labels: affects_elytron > Fix For: 1.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-577) Where a complex attribute contains a Object type that contains an ObjectList the value type of the ObjectList is not returned in the resource description.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-577?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFCORE-577: ------------------------------------ Summary: Where a complex attribute contains a Object type that contains an ObjectList the value type of the ObjectList is not returned in the resource description. (was: Where a complex attribute is a list of lists, the inner list does not have it's value-type reported.) > Where a complex attribute contains a Object type that contains an ObjectList the value type of the ObjectList is not returned in the resource description. > ---------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-577 > URL: https://issues.jboss.org/browse/WFCORE-577 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-577) Where a complex attribute is a list of lists, the inner list does not have it's value-type reported.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-577: --------------------------------------- Summary: Where a complex attribute is a list of lists, the inner list does not have it's value-type reported. Key: WFCORE-577 URL: https://issues.jboss.org/browse/WFCORE-577 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.0.0.Beta1 -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3657) Injection not working on JAXWS handlers specified with @HandlerChain on service endpoint interfaces

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-3657?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated WFLY-3657: ---------------------------------- Fix Version/s: 9.0.0.Beta1 > Injection not working on JAXWS handlers specified with @HandlerChain on service endpoint interfaces > --------------------------------------------------------------------------------------------------- > > Key: WFLY-3657 > URL: https://issues.jboss.org/browse/WFLY-3657 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.1.0.Final > Environment: Ubuntu 12.04 > JDK 1.8.0_11 > Reporter: Thomas Kriechbaum > Assignee: Alessio Soldano > Fix For: 9.0.0.Beta1 > > Attachments: jaxws-handler-war.zip, wildfly-test-soapui-project.xml > > > According to the JavaEE spec JAXWS-handlers should support injection (@Inject, @EJB), @PostConstruct and @PreDestroy. > In my test case (top-down approach, handler class is defined within *_handler.xml) @PostCunstruct works, but managed beans (CDI, EJB) are not injected via @Inject or @EJB. > Possible workaround for EJBs: manual JNDI-lookup within @PostConstruct method. For CDI-managed beans you have to lookup the BeanManager and load the desired bean yourself. > It seems, that this issue should have been addressed by WFLY-2362. But it is still does not work. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3657) Injection not working on JAXWS handlers specified with @HandlerChain on service endpoint interfaces

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-3657?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on WFLY-3657: --------------------------------------- I confirm this is a bug; basically, org.jboss.as.webservices.injection.WSHandlerChainAnnotationProcessor is not considering @HandlerChain annotation that could be on service endpoint interfaces referenced by @WebService(endpointInterface="..." ) on endpoint implementations. This is covered by JSR-181 spec, section 4.6.1: "The @HandlerChain annotation MAY be present on the endpoint interface and service implementation bean. The service implementation bean’s @HandlerChain is used if @HandlerChain is present on both." > Injection not working on JAXWS handlers specified with @HandlerChain on service endpoint interfaces > --------------------------------------------------------------------------------------------------- > > Key: WFLY-3657 > URL: https://issues.jboss.org/browse/WFLY-3657 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.1.0.Final > Environment: Ubuntu 12.04 > JDK 1.8.0_11 > Reporter: Thomas Kriechbaum > Assignee: Alessio Soldano > Attachments: jaxws-handler-war.zip, wildfly-test-soapui-project.xml > > > According to the JavaEE spec JAXWS-handlers should support injection (@Inject, @EJB), @PostConstruct and @PreDestroy. > In my test case (top-down approach, handler class is defined within *_handler.xml) @PostCunstruct works, but managed beans (CDI, EJB) are not injected via @Inject or @EJB. > Possible workaround for EJBs: manual JNDI-lookup within @PostConstruct method. For CDI-managed beans you have to lookup the BeanManager and load the desired bean yourself. > It seems, that this issue should have been addressed by WFLY-2362. But it is still does not work. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3657) Injection not working on JAXWS handlers specified with @HandlerChain on service endpoint interfaces

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-3657?page=com.atlassian.jira.plugin.... ] Alessio Soldano updated WFLY-3657: ---------------------------------- Summary: Injection not working on JAXWS handlers specified with @HandlerChain on service endpoint interfaces (was: JAXWS handlers do not support injection) > Injection not working on JAXWS handlers specified with @HandlerChain on service endpoint interfaces > --------------------------------------------------------------------------------------------------- > > Key: WFLY-3657 > URL: https://issues.jboss.org/browse/WFLY-3657 > Project: WildFly > Issue Type: Bug > Components: Web Services > Affects Versions: 8.1.0.Final > Environment: Ubuntu 12.04 > JDK 1.8.0_11 > Reporter: Thomas Kriechbaum > Assignee: Alessio Soldano > Attachments: jaxws-handler-war.zip, wildfly-test-soapui-project.xml > > > According to the JavaEE spec JAXWS-handlers should support injection (@Inject, @EJB), @PostConstruct and @PreDestroy. > In my test case (top-down approach, handler class is defined within *_handler.xml) @PostCunstruct works, but managed beans (CDI, EJB) are not injected via @Inject or @EJB. > Possible workaround for EJBs: manual JNDI-lookup within @PostConstruct method. For CDI-managed beans you have to lookup the BeanManager and load the desired bean yourself. > It seems, that this issue should have been addressed by WFLY-2362. But it is still does not work. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-733) Unify Drools and jBPM execution servers

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-733?page=com.atlassian.jira.plugin... ] Edson Tirelli updated DROOLS-733: --------------------------------- Description: This is a placeholder parent ticket for the merge of the code from Drools and jBPM execution servers into a single server. The new server should be standalone, free of UI code, support remote interfaces, and comply to all requirements from both Drools and jBPM. It should try to avoid the use of technologies that cause issues on different containers (like CDI), and be as lightweight as possible for cloud deployment. Initial open questions include: * support to databases and persistence: should this be a per-container configuration or per-kjar configuration? * can a single deployment model be used for both drools and jbpm? * how to apply the security model from jbpm? * does the workbench need to continue to support remote REST calls for deployments or can it be moved completely out of it? * workbench UI consolidation for exec servers was: This is a placeholder parent ticket for the merge of the code from Drools and jBPM execution servers into a single server. The new server should be standalone, free of UI code, support remote interfaces, and comply to all requirements from both Drools and jBPM. It should try to avoid the use of technologies that cause issues on different containers (like CDI), and be as lightweight as possible for cloud deployment. Initial open questions include: * support to databases and persistence: should this be a per-container configuration or per-kjar configuration? * can a single deployment model be used for both drools and jbpm? * how to apply the security model from jbpm? * does the workbench need to continue to support remote REST calls for deployments or can it be moved completely out of it? > Unify Drools and jBPM execution servers > --------------------------------------- > > Key: DROOLS-733 > URL: https://issues.jboss.org/browse/DROOLS-733 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 6.2.0.Final > Reporter: Edson Tirelli > Assignee: Edson Tirelli > Fix For: 6.3.0.Final > > > This is a placeholder parent ticket for the merge of the code from Drools and jBPM execution servers into a single server. > The new server should be standalone, free of UI code, support remote interfaces, and comply to all requirements from both Drools and jBPM. > It should try to avoid the use of technologies that cause issues on different containers (like CDI), and be as lightweight as possible for cloud deployment. > Initial open questions include: > * support to databases and persistence: should this be a per-container configuration or per-kjar configuration? > * can a single deployment model be used for both drools and jbpm? > * how to apply the security model from jbpm? > * does the workbench need to continue to support remote REST calls for deployments or can it be moved completely out of it? > * workbench UI consolidation for exec servers -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-510) Fix filtering in domain mode

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-510?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFCORE-510: --------------------------------------- Assignee: ehsavoie Hugonnet (was: Brian Stansberry) > Fix filtering in domain mode > ---------------------------- > > Key: WFCORE-510 > URL: https://issues.jboss.org/browse/WFCORE-510 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Harald Pehl > Assignee: ehsavoie Hugonnet > Fix For: 1.0.0.Beta1 > > > The overall result for query operations in domain mode does not filter undefined results. Executing the following operation, will yield three results. However the last result needs to be filtered: > {code} > [domain@localhost:9990 /] /host=master/server-config=*:query(select=[name, status, auto-start], where={auto-start=>true}) > { > "outcome" => "success", > "result" => [ > { > "address" => [ > ("host" => "master"), > ("server-config" => "server-one") > ], > "outcome" => undefined, > "result" => { > "name" => "server-one", > "status" => "STARTED", > "auto-start" => true > } > }, > { > "address" => [ > ("host" => "master"), > ("server-config" => "server-two") > ], > "outcome" => undefined, > "result" => { > "name" => "server-two", > "status" => "STARTED", > "auto-start" => true > } > }, > { > "address" => [ > ("host" => "master"), > ("server-config" => "server-three") > ], > "outcome" => undefined, > "result" => undefined > } > ], > "server-groups" => undefined > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-510) Fix filtering in domain mode

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-510?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-510: ----------------------------------------- No, I haven't looked at it. Is there a reason to believe the problem is outside the handling for the query op itself? > Fix filtering in domain mode > ---------------------------- > > Key: WFCORE-510 > URL: https://issues.jboss.org/browse/WFCORE-510 > Project: WildFly Core > Issue Type: Sub-task > Components: Domain Management > Reporter: Harald Pehl > Assignee: Brian Stansberry > Fix For: 1.0.0.Beta1 > > > The overall result for query operations in domain mode does not filter undefined results. Executing the following operation, will yield three results. However the last result needs to be filtered: > {code} > [domain@localhost:9990 /] /host=master/server-config=*:query(select=[name, status, auto-start], where={auto-start=>true}) > { > "outcome" => "success", > "result" => [ > { > "address" => [ > ("host" => "master"), > ("server-config" => "server-one") > ], > "outcome" => undefined, > "result" => { > "name" => "server-one", > "status" => "STARTED", > "auto-start" => true > } > }, > { > "address" => [ > ("host" => "master"), > ("server-config" => "server-two") > ], > "outcome" => undefined, > "result" => { > "name" => "server-two", > "status" => "STARTED", > "auto-start" => true > } > }, > { > "address" => [ > ("host" => "master"), > ("server-config" => "server-three") > ], > "outcome" => undefined, > "result" => undefined > } > ], > "server-groups" => undefined > } > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 3 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 March 2015