[JBoss JIRA] (WFLY-5941) IllegalArgumentException when injecting dependencies for SAR
by John Farrelly (JIRA)
[ https://issues.jboss.org/browse/WFLY-5941?page=com.atlassian.jira.plugin.... ]
John Farrelly updated WFLY-5941:
--------------------------------
Description:
I created a service archive based on the code in {{wildfly/sar/src/test/_java}}. I have the following files in my {{standalone/deployment}} directory:
{noformat}
.
|-- my-test.sar
| |-- META-INF
| | `-- jboss-service.xml
| `-- org
| `-- jboss
| `-- as
| `-- service
| |-- LegacyService.class
| `-- LegacyServiceMBean.class
`-- my-test.sar.dodeploy
{noformat}
I get the following error when WildFly tries to deploy the sar:
{noformat}
10:47:01,472 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.mbean.service.jboss:name=testTwo,type=service.create: org.jboss.msc.service.StartException in service jboss.mbean.service.jboss:name=testTwo,type=service.create: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
Caused by: org.jboss.msc.inject.InjectionException: Injection failed
at org.jboss.msc.inject.MethodInjector.inject(MethodInjector.java:102) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at org.jboss.msc.service.ServiceControllerImpl.doInject(ServiceControllerImpl.java:1672) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at org.jboss.msc.service.ServiceControllerImpl.access$2000(ServiceControllerImpl.java:51) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.performInjections(ServiceControllerImpl.java:1917) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1876) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
... 3 more
Caused by: java.lang.IllegalArgumentException: argument type mismatch
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_60]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_60]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
at org.jboss.msc.inject.MethodInjector.inject(MethodInjector.java:92) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
... 7 more
{noformat}
Attached is the sar file that I tried to deploy. The {{META-INF/jboss-service.xml}} file has the following content:
{code:xml}
<server xmlns="urn:jboss:service:7.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:jboss:service:7.0 jboss-service_7_0.xsd">
<mbean name="jboss:name=test,type=service" code="org.jboss.as.service.LegacyService">
<constructor>
<arg value="Test Value" type="java.lang.String"/>
</constructor>
</mbean>
<mbean name="jboss:name=testTwo,type=service" code="org.jboss.as.service.LegacyService">
<depends optional-attribute-name="other">jboss:name=test,type=service</depends>
<attribute name="somethingElse">
<value-factory bean="jboss:name=test,type=service" method="appendSomethingElse">
<parameter class="java.lang.String">more value</parameter>
</value-factory>
</attribute>
</mbean>
<mbean name="jboss:name=testThree,type=service" code="org.jboss.as.service.LegacyService">
<attribute name="other">
<inject bean="jboss:name=testTwo,type=service" property="other"/>
</attribute>
<attribute name="somethingElse">Another test value</attribute>
</mbean>
</server>
{code}
The code for {{LegacyService}} is as follows:
{code:java}
package org.jboss.as.service;
import org.jboss.logging.Logger;
/**
* @author John E. Bailey
*/
public class LegacyService implements LegacyServiceMBean {
private static final Logger logger = Logger.getLogger(LegacyService.class);
private LegacyService other;
private String somethingElse;
public LegacyService() {
}
public LegacyService(String somethingElse) {
this.somethingElse = somethingElse;
}
public void setOther(LegacyService other) {
this.other = other;
}
public LegacyService getOther() {
return other;
}
public String getSomethingElse() {
return somethingElse;
}
public String appendSomethingElse(String more) {
return somethingElse + " - " + more;
}
public void setSomethingElse(String somethingElse) {
this.somethingElse = somethingElse;
}
public void start() {
logger.info("Started");
}
public void stop() {
logger.info("Stopped");
}
}
{code}
The code for {{LegacyServiceMBean.java}} is:
{code:java}
package org.jboss.as.service;
/**
* @author John Bailey
*/
public interface LegacyServiceMBean {
}
{code}
was:
We use Orbacus as our CORBA implementation, and in our application we wish to use CORBA classes only from the orbacus module, and not the JDK/WildFly bundled CORBA.
In the {{jboss-deployment-structure.xml}} file of our {{ear}} file, we have the following:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
<deployment>
<exclusions>
<module name="javax.orb.api" />
<module name="org.omg.api" />
</exclusions>
<dependencies>
<module name="com.ooc.orbacus" export="true"/>
<module name="org.apache.commons.logging" export="true" />
<module name="org.apache.commons.collections" export="true" />
<module name="org.apache.log4j" export="true" />
<module name="org.dom4j" export="true" />
<module name="org.jdom" export="true" />
<module name="javax.faces.api" slot="mojarra-2.1.23" export="true"/>
<module name="com.sun.jsf-impl" slot="mojarra-2.1.23" export="true"/>
<module name="org.jboss.ejb-client" export="true" />
<module name="org.jboss.remote-naming" export="true" />
<module name="org.jboss.remoting3" export="true" />
<module name="org.apache.xerces" />
<!-- dependency for richfaces -->
<module name="com.google.guava" slot="11.0.2" export="true"/>
</dependencies>
</deployment>
...
{code}
However, despite excluding the {{javax.orb.api}} module, I can see that {{org.omg.PortableServer.Servant}} is loaded from that module instead of being loaded from our {{com.ooc.orbacus}} module. This causes our application to fail.
Debugging through the jboss module loader, I can see that it considers both {{javax.orb.api}} and {{com.ooc.orbacus}} as prodivers of the {{org/omg/PortableServer}} path. I am not sure why {{javax.orb.api}} is being considered when it has been excluded in the deployment descriptor for the application.
> IllegalArgumentException when injecting dependencies for SAR
> ------------------------------------------------------------
>
> Key: WFLY-5941
> URL: https://issues.jboss.org/browse/WFLY-5941
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 10.0.0.CR4
> Environment: Red Hat Enterprise Linux Server release 7.1 (Maipo)
> Linux 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> Reporter: John Farrelly
> Assignee: Stuart Douglas
>
> I created a service archive based on the code in {{wildfly/sar/src/test/_java}}. I have the following files in my {{standalone/deployment}} directory:
> {noformat}
> .
> |-- my-test.sar
> | |-- META-INF
> | | `-- jboss-service.xml
> | `-- org
> | `-- jboss
> | `-- as
> | `-- service
> | |-- LegacyService.class
> | `-- LegacyServiceMBean.class
> `-- my-test.sar.dodeploy
> {noformat}
> I get the following error when WildFly tries to deploy the sar:
> {noformat}
> 10:47:01,472 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.mbean.service.jboss:name=testTwo,type=service.create: org.jboss.msc.service.StartException in service jboss.mbean.service.jboss:name=testTwo,type=service.create: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> Caused by: org.jboss.msc.inject.InjectionException: Injection failed
> at org.jboss.msc.inject.MethodInjector.inject(MethodInjector.java:102) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl.doInject(ServiceControllerImpl.java:1672) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl.access$2000(ServiceControllerImpl.java:51) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.performInjections(ServiceControllerImpl.java:1917) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1876) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> ... 3 more
> Caused by: java.lang.IllegalArgumentException: argument type mismatch
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_60]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_60]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_60]
> at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_60]
> at org.jboss.msc.inject.MethodInjector.inject(MethodInjector.java:92) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
> ... 7 more
> {noformat}
> Attached is the sar file that I tried to deploy. The {{META-INF/jboss-service.xml}} file has the following content:
> {code:xml}
> <server xmlns="urn:jboss:service:7.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:jboss:service:7.0 jboss-service_7_0.xsd">
> <mbean name="jboss:name=test,type=service" code="org.jboss.as.service.LegacyService">
> <constructor>
> <arg value="Test Value" type="java.lang.String"/>
> </constructor>
> </mbean>
> <mbean name="jboss:name=testTwo,type=service" code="org.jboss.as.service.LegacyService">
> <depends optional-attribute-name="other">jboss:name=test,type=service</depends>
> <attribute name="somethingElse">
> <value-factory bean="jboss:name=test,type=service" method="appendSomethingElse">
> <parameter class="java.lang.String">more value</parameter>
> </value-factory>
> </attribute>
> </mbean>
> <mbean name="jboss:name=testThree,type=service" code="org.jboss.as.service.LegacyService">
> <attribute name="other">
> <inject bean="jboss:name=testTwo,type=service" property="other"/>
> </attribute>
> <attribute name="somethingElse">Another test value</attribute>
> </mbean>
> </server>
> {code}
> The code for {{LegacyService}} is as follows:
> {code:java}
> package org.jboss.as.service;
> import org.jboss.logging.Logger;
> /**
> * @author John E. Bailey
> */
> public class LegacyService implements LegacyServiceMBean {
> private static final Logger logger = Logger.getLogger(LegacyService.class);
> private LegacyService other;
> private String somethingElse;
> public LegacyService() {
> }
> public LegacyService(String somethingElse) {
> this.somethingElse = somethingElse;
> }
> public void setOther(LegacyService other) {
> this.other = other;
> }
> public LegacyService getOther() {
> return other;
> }
> public String getSomethingElse() {
> return somethingElse;
> }
> public String appendSomethingElse(String more) {
> return somethingElse + " - " + more;
> }
> public void setSomethingElse(String somethingElse) {
> this.somethingElse = somethingElse;
> }
> public void start() {
> logger.info("Started");
> }
> public void stop() {
> logger.info("Stopped");
> }
> }
> {code}
> The code for {{LegacyServiceMBean.java}} is:
> {code:java}
> package org.jboss.as.service;
> /**
> * @author John Bailey
> */
> public interface LegacyServiceMBean {
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5941) IllegalArgumentException when injecting dependencies for SAR
by John Farrelly (JIRA)
John Farrelly created WFLY-5941:
-----------------------------------
Summary: IllegalArgumentException when injecting dependencies for SAR
Key: WFLY-5941
URL: https://issues.jboss.org/browse/WFLY-5941
Project: WildFly
Issue Type: Bug
Components: Class Loading
Affects Versions: 10.0.0.CR4
Environment: Red Hat Enterprise Linux Server release 7.1 (Maipo)
Linux 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
Reporter: John Farrelly
Assignee: Stuart Douglas
We use Orbacus as our CORBA implementation, and in our application we wish to use CORBA classes only from the orbacus module, and not the JDK/WildFly bundled CORBA.
In the {{jboss-deployment-structure.xml}} file of our {{ear}} file, we have the following:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
<deployment>
<exclusions>
<module name="javax.orb.api" />
<module name="org.omg.api" />
</exclusions>
<dependencies>
<module name="com.ooc.orbacus" export="true"/>
<module name="org.apache.commons.logging" export="true" />
<module name="org.apache.commons.collections" export="true" />
<module name="org.apache.log4j" export="true" />
<module name="org.dom4j" export="true" />
<module name="org.jdom" export="true" />
<module name="javax.faces.api" slot="mojarra-2.1.23" export="true"/>
<module name="com.sun.jsf-impl" slot="mojarra-2.1.23" export="true"/>
<module name="org.jboss.ejb-client" export="true" />
<module name="org.jboss.remote-naming" export="true" />
<module name="org.jboss.remoting3" export="true" />
<module name="org.apache.xerces" />
<!-- dependency for richfaces -->
<module name="com.google.guava" slot="11.0.2" export="true"/>
</dependencies>
</deployment>
...
{code}
However, despite excluding the {{javax.orb.api}} module, I can see that {{org.omg.PortableServer.Servant}} is loaded from that module instead of being loaded from our {{com.ooc.orbacus}} module. This causes our application to fail.
Debugging through the jboss module loader, I can see that it considers both {{javax.orb.api}} and {{com.ooc.orbacus}} as prodivers of the {{org/omg/PortableServer}} path. I am not sure why {{javax.orb.api}} is being considered when it has been excluded in the deployment descriptor for the application.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5941) IllegalArgumentException when injecting dependencies for SAR
by John Farrelly (JIRA)
[ https://issues.jboss.org/browse/WFLY-5941?page=com.atlassian.jira.plugin.... ]
John Farrelly updated WFLY-5941:
--------------------------------
Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/8537)
> IllegalArgumentException when injecting dependencies for SAR
> ------------------------------------------------------------
>
> Key: WFLY-5941
> URL: https://issues.jboss.org/browse/WFLY-5941
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 10.0.0.CR4
> Environment: Red Hat Enterprise Linux Server release 7.1 (Maipo)
> Linux 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> Reporter: John Farrelly
> Assignee: Stuart Douglas
>
> We use Orbacus as our CORBA implementation, and in our application we wish to use CORBA classes only from the orbacus module, and not the JDK/WildFly bundled CORBA.
> In the {{jboss-deployment-structure.xml}} file of our {{ear}} file, we have the following:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
> <deployment>
> <exclusions>
> <module name="javax.orb.api" />
> <module name="org.omg.api" />
> </exclusions>
> <dependencies>
> <module name="com.ooc.orbacus" export="true"/>
> <module name="org.apache.commons.logging" export="true" />
> <module name="org.apache.commons.collections" export="true" />
> <module name="org.apache.log4j" export="true" />
> <module name="org.dom4j" export="true" />
> <module name="org.jdom" export="true" />
> <module name="javax.faces.api" slot="mojarra-2.1.23" export="true"/>
> <module name="com.sun.jsf-impl" slot="mojarra-2.1.23" export="true"/>
> <module name="org.jboss.ejb-client" export="true" />
> <module name="org.jboss.remote-naming" export="true" />
> <module name="org.jboss.remoting3" export="true" />
> <module name="org.apache.xerces" />
> <!-- dependency for richfaces -->
> <module name="com.google.guava" slot="11.0.2" export="true"/>
> </dependencies>
> </deployment>
> ...
> {code}
> However, despite excluding the {{javax.orb.api}} module, I can see that {{org.omg.PortableServer.Servant}} is loaded from that module instead of being loaded from our {{com.ooc.orbacus}} module. This causes our application to fail.
> Debugging through the jboss module loader, I can see that it considers both {{javax.orb.api}} and {{com.ooc.orbacus}} as prodivers of the {{org/omg/PortableServer}} path. I am not sure why {{javax.orb.api}} is being considered when it has been excluded in the deployment descriptor for the application.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5940) Cannot exclude java.orb.api module
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-5940:
------------------------------------
Summary: Cannot exclude java.orb.api module
Key: WFLY-5940
URL: https://issues.jboss.org/browse/WFLY-5940
Project: WildFly
Issue Type: Bug
Components: Class Loading
Affects Versions: 10.0.0.CR4
Environment: Red Hat Enterprise Linux Server release 7.1 (Maipo)
Linux 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
Reporter: John Farrelly
Assignee: Stuart Douglas
We use Orbacus as our CORBA implementation, and in our application we wish to use CORBA classes only from the orbacus module, and not the JDK/WildFly bundled CORBA.
In the {{jboss-deployment-structure.xml}} file of our {{ear}} file, we have the following:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
<deployment>
<exclusions>
<module name="javax.orb.api" />
<module name="org.omg.api" />
</exclusions>
<dependencies>
<module name="com.ooc.orbacus" export="true"/>
<module name="org.apache.commons.logging" export="true" />
<module name="org.apache.commons.collections" export="true" />
<module name="org.apache.log4j" export="true" />
<module name="org.dom4j" export="true" />
<module name="org.jdom" export="true" />
<module name="javax.faces.api" slot="mojarra-2.1.23" export="true"/>
<module name="com.sun.jsf-impl" slot="mojarra-2.1.23" export="true"/>
<module name="org.jboss.ejb-client" export="true" />
<module name="org.jboss.remote-naming" export="true" />
<module name="org.jboss.remoting3" export="true" />
<module name="org.apache.xerces" />
<!-- dependency for richfaces -->
<module name="com.google.guava" slot="11.0.2" export="true"/>
</dependencies>
</deployment>
...
{code}
However, despite excluding the {{javax.orb.api}} module, I can see that {{org.omg.PortableServer.Servant}} is loaded from that module instead of being loaded from our {{com.ooc.orbacus}} module. This causes our application to fail.
Debugging through the jboss module loader, I can see that it considers both {{javax.orb.api}} and {{com.ooc.orbacus}} as prodivers of the {{org/omg/PortableServer}} path. I am not sure why {{javax.orb.api}} is being considered when it has been excluded in the deployment descriptor for the application.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5484) Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-5484?page=com.atlassian.jira.plugin.... ]
Richard Janík commented on WFLY-5484:
-------------------------------------
Yes, Rado's answer is correct.
> Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5484
> URL: https://issues.jboss.org/browse/WFLY-5484
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Richard Janík
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 10.0.0.CR5
>
> Attachments: reproducer-jbeap-1282.zip
>
>
> See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect
> This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5907) NullPointerException during deployment ejb-ref with mappedName
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5907?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-5907:
------------------------------------
Assignee: Stuart Douglas
> NullPointerException during deployment ejb-ref with mappedName
> --------------------------------------------------------------
>
> Key: WFLY-5907
> URL: https://issues.jboss.org/browse/WFLY-5907
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.2.Final
> Reporter: Marco Zanker
> Assignee: Stuart Douglas
>
> If deploying a ejb3 SSB with a ejb reference to another bean (in my case an old ejb 2 SSB) with a mappedName-parameter, a NullPointerException occurs.
> @EJBs({
> @EJB(name = "ejb/MyOldEJB2LocalHome", beanInterface=MyOldEJB2LocalHome.class, beanName="oldejb.jar#MyOldEJB2", mappedName = "oldejb/MyOldEJB2Local"),
> })
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.process(EjbResourceInjectionA
> nnotationProcessor.java:166)
> at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.processClass(EjbResourceInjec
> tionAnnotationProcessor.java:146)
> at org.jboss.as.ejb3.deployment.processors.EjbResourceInjectionAnnotationProcessor.deploy(EjbResourceInjectionAn
> notationProcessor.java:106)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> Seems, if mappedName is declared, always a NullPointerException occurs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5922) Cannot exclude java.orb.api module
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5922?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-5922:
------------------------------------
Priority: Major (was: Blocker)
Assignee: Stuart Douglas (was: David Lloyd)
> Cannot exclude java.orb.api module
> ----------------------------------
>
> Key: WFLY-5922
> URL: https://issues.jboss.org/browse/WFLY-5922
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 10.0.0.CR4
> Environment: Red Hat Enterprise Linux Server release 7.1 (Maipo)
> Linux 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> Reporter: John Farrelly
> Assignee: Stuart Douglas
>
> We use Orbacus as our CORBA implementation, and in our application we wish to use CORBA classes only from the orbacus module, and not the JDK/WildFly bundled CORBA.
> In the {{jboss-deployment-structure.xml}} file of our {{ear}} file, we have the following:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
> <deployment>
> <exclusions>
> <module name="javax.orb.api" />
> <module name="org.omg.api" />
> </exclusions>
> <dependencies>
> <module name="com.ooc.orbacus" export="true"/>
> <module name="org.apache.commons.logging" export="true" />
> <module name="org.apache.commons.collections" export="true" />
> <module name="org.apache.log4j" export="true" />
> <module name="org.dom4j" export="true" />
> <module name="org.jdom" export="true" />
> <module name="javax.faces.api" slot="mojarra-2.1.23" export="true"/>
> <module name="com.sun.jsf-impl" slot="mojarra-2.1.23" export="true"/>
> <module name="org.jboss.ejb-client" export="true" />
> <module name="org.jboss.remote-naming" export="true" />
> <module name="org.jboss.remoting3" export="true" />
> <module name="org.apache.xerces" />
> <!-- dependency for richfaces -->
> <module name="com.google.guava" slot="11.0.2" export="true"/>
> </dependencies>
> </deployment>
> ...
> {code}
> However, despite excluding the {{javax.orb.api}} module, I can see that {{org.omg.PortableServer.Servant}} is loaded from that module instead of being loaded from our {{com.ooc.orbacus}} module. This causes our application to fail.
> Debugging through the jboss module loader, I can see that it considers both {{javax.orb.api}} and {{com.ooc.orbacus}} as prodivers of the {{org/omg/PortableServer}} path. I am not sure why {{javax.orb.api}} is being considered when it has been excluded in the deployment descriptor for the application.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1226) undeploying disabled deployment stops service for same runtime-name in DeploymentUndeployHandler
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1226?page=com.atlassian.jira.plugi... ]
Chao Wang commented on WFCORE-1226:
-----------------------------------
Yes, it exists in both versions.
> undeploying disabled deployment stops service for same runtime-name in DeploymentUndeployHandler
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1226
> URL: https://issues.jboss.org/browse/WFCORE-1226
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.4.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Attachments: WFCORE-1226-wildflytest.patch, WFCORE-1226.patch
>
>
> {noformat}
> 1. Start EAP 6.4.4 in domain mode and deploy application using following CLI command:
> ~~
> [domain@localhost:9999 /] deploy /Applications/WebApp-1.war --server-groups=main-server-group --name=WebApp-1.war --runtime-name=WebApp-1.war
> ~~~
> 2. Deploy next version of application in "disabled" state with same "runtime-name"
> ~~~
> [domain@localhost:9999 /] deploy /Applications/WebApp-2.war --disabled --name=WebApp-2.war --runtime-name=WebApp-1.war
> ~~~
> 3. Now use replace-deployment command to access latest version of application:
> ~~~
> [domain@localhost:9999 /] /server-group=main-server-group:replace-deployment(name=WebApp-2.war,to-replace=WebApp-1.war)
> ~~~
> its working fine,laest version of application is accessable.
> 4. Now try to undeploy old version of application
> ~~~
> /server-group=main-server-group/deployment=WebApp-1.war:undeploy()
> ~~~
> After undploying older version, we are not able to access(404) latest version of application(WebApp-2.war) as well.To access it we have to redeploy it.
> Same steps are working fine in Standalone mode.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1270) Intermittent NPE registering a slave HC in mixed-domain test suite
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1270?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1270:
-------------------------------------
Affects Version/s: 2.0.5.Final
> Intermittent NPE registering a slave HC in mixed-domain test suite
> ------------------------------------------------------------------
>
> Key: WFCORE-1270
> URL: https://issues.jboss.org/browse/WFCORE-1270
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Test Suite
> Affects Versions: 2.0.5.Final
> Reporter: Brian Stansberry
> Assignee: Kabir Khan
>
> I've occasionally seen test failures in the mixed domain tests when a testsuite cannot start because the slave HC can't register due to an NPE on the master:
> For example:
> http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=82653&tab=buil...
> Critical log details:
> {code}&#27;[0m16:16:15,252 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final-redhat-1
> &#27;[0m&#27;[0m16:16:15,363 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> &#27;[0m[Host Controller] &#27;[0m16:16:15,871 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.3.Final-redhat-1&#27;[0m
> [Host Controller] &#27;[0m&#27;[0m16:16:16,015 INFO [org.jboss.msc] (main) JBoss MSC version 1.1.5.Final-redhat-1&#27;[0m
> [Host Controller] &#27;[0m&#27;[0m16:16:16,068 INFO [org.jboss.as] (MSC service thread 1-4) JBAS015899: JBoss EAP 6.3.0.GA (AS 7.4.0.Final-redhat-19) starting&#27;[0m
> [Host Controller] &#27;[0m&#27;[0m16:16:16,625 INFO [org.xnio] (MSC service thread 1-2) XNIO Version 3.0.10.GA-redhat-1&#27;[0m
> [Host Controller] &#27;[0m&#27;[0m16:16:16,629 INFO [org.xnio.nio] (MSC service thread 1-2) XNIO NIO Implementation Version 3.0.10.GA-redhat-1&#27;[0m
> [Host Controller] &#27;[0m&#27;[0m16:16:16,657 INFO [org.jboss.remoting] (MSC service thread 1-2) JBoss Remoting version (unknown)&#27;[0m
> [Host Controller] &#27;[0m&#27;[0m16:16:16,705 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on [::1]:19999&#27;[0m
> INFO [org.jboss.as.test.integration.domain.management.util.DomainLifecycleUtil] ServerIdentity{name=server-one, host=slave, server-group=other-server-group} status is starting
> [Host Controller] &#27;[0m&#27;[31m16:16:17,913 ERROR [org.jboss.as.controller.management-operation] (Host Controller Service Threads - 50) WFLYCTL0013: Operation ("read-master-domain-model") failed - address: ([]): java.lang.NullPointerException&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.registry.OperationTransformerRegistry$1.getResourceTransformer(OperationTransformerRegistry.java:83)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.transform.ResourceTransformationContextImpl.resolveTransformer(ResourceTransformationContextImpl.java:235)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.transform.ResourceTransformationContextImpl.processChild(ResourceTransformationContextImpl.java:285)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.transform.ResourceTransformationContextImpl.processChildren(ResourceTransformationContextImpl.java:254)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.transform.ResourceTransformer$1.transformResource(ResourceTransformer.java:53)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.transform.description.TransformingDescription$3.invokeNext(TransformingDescription.java:161)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.transform.description.AttributeTransformationRule.transformResource(AttributeTransformationRule.java:103)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.transform.description.TransformingDescription.transformResource(TransformingDescription.java:167)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.transform.ResourceTransformationContextImpl.processChild(ResourceTransformationContextImpl.java:289)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.transform.ResourceTransformationContextImpl.processChildren(ResourceTransformationContextImpl.java:254)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.transform.ResourceTransformer$1.transformResource(ResourceTransformer.java:53)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.transform.TransformersImpl.transformRootResource(TransformersImpl.java:115)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.domain.controller.operations.ReadMasterDomainModelUtil.readMasterDomainResourcesForInitialConnect(ReadMasterDomainModelUtil.java:88)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.domain.controller.operations.ReadDomainModelHandler.execute(ReadDomainModelHandler.java:51)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1343)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:395)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:408)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.host.controller.DomainModelControllerService.access$900(DomainModelControllerService.java:175)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:1229)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.host.controller.mgmt.HostControllerRegistrationHandler$RegistrationContext.processRegistration(HostControllerRegistrationHandler.java:424)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.host.controller.mgmt.HostControllerRegistrationHandler$RegistrationContext.access$400(HostControllerRegistrationHandler.java:334)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.host.controller.mgmt.HostControllerRegistrationHandler$InitiateRegistrationHandler$1.execute(HostControllerRegistrationHandler.java:230)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:465)&#27;[0m
> [Host Controller] &#27;[31m at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)&#27;[0m
> [Host Controller] &#27;[31m at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)&#27;[0m
> [Host Controller] &#27;[31m at java.lang.Thread.run(Thread.java:745)&#27;[0m
> [Host Controller] &#27;[31m at org.jboss.threads.JBossThread.run(JBossThread.java:320)&#27;[0m
> [Host Controller] &#27;[31m&#27;[0m
> [Host Controller] &#27;[0m&#27;[33m16:16:17,935 WARN [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010900: Could not connect to remote domain controller at remote://[::1]:9999 -- 1-$-WFLYCTL0158: Operation handler failed: java.lang.NullPointerException&#27;[0m
> [Host Controller] &#27;[33m&#27;[0m&#27;[33m16:16:17,936 WARN [org.jboss.as.host.controller] (Controller Boot Thread) JBAS016581: No domain controller discovery options remain.&#27;[0m
> [Host Controller] &#27;[33m&#27;[0m&#27;[31m16:16:17,939 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS016519: Tried all domain controller discovery option(s) but unable to connect&#27;[0m
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months