anonymous wrote : com.thesearchagency.mms.service.user.UserException: Non matching type for inject of field: com.these | archagency.mms.service.customization.ICustomizationRemote com.thesearchagency.mms.service.user.impl. | UserEJB.theCustomizationService for type: $Proxy220 of jndiName env/com.thesearchagency.mms.service. | user.impl.UserEJB/theCustomizationService | intfs: , com.thesearchagency.mms.service.customization.ICustomizationRemote, org.jboss.ejb3.JBossPro | xy, javax.ejb.EJBObject; nested exception is: | java.lang.RuntimeException: Non matching type for inject of field: com.thesearchagency.mms.service. | customization.ICustomizationRemote com.thesearchagency.mms.service.user.impl.UserEJB.theCustomizatio | nService for type: $Proxy220 of jndiName env/com.thesearchagency.mms.service.user.impl.UserEJB/theCu | stomizationService | intfs: , com.thesearchagency.mms.service.customization.ICustomizationRemote, org.jboss.ejb3.JBossPro | xy, javax.ejb.EJBObject | As suspected, it's the similar to what we fixed as part of EJBTHREE-1889 for AS-5. anonymous wrote : | Also if this is a bug is there any way to patch it in a JBoss 4.2.1.GA environment? The 4.x community branch is way too old and is no longer being developed. The code too is vastly different from the current state. The possible options are: 1) Upgrade to latest 5.1.0 AS and you start using the EJB3 plugins 2) Checkout AS 4.x branch from source and then you will have to manually create the patch and build the AS. 3) If you have a support contract with the enterprise edition of AS (the EAP version), you can always file a ticket and the issue will be fixed in the enterprise edition branch and will be made available to you. anonymous wrote : | So I am assuming this is a bug in JBoss 4.2.1 and Remote EJB calls from a client are not possible... ? Remote calls are possible. The problem you are running into is that you have isolated your deployments and are packaging the EJB interfaces in each deployment (a valid case, btw). The proxy being bound is JNDI uses a different classloader (corresponding to deployment A) and the injection/lookup happens using a different classloader (corresponding to deployment B) and hence the classcast exception. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4265533#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...