-
1. Re: testing with @Resource definition
rcernich Sep 17, 2014 2:50 PM (in response to mlybarger)Hey Mark,
Have you tried adding the NamingMixIn to your test? This should add a naming context for your test.
Hope that helps,
Rob
-
2. Re: Re: testing with @Resource definition
mlybarger Sep 17, 2014 3:10 PM (in response to rcernich)Yes, I do have a naming context, but the @Resource injection points don't seem to be getting resolved. The lookup2 method returns as expected.
import javax.annotation.Resource;
import javax.inject.Named;
import javax.naming.InitialContext;
import javax.naming.NamingException;
@Named
public class TestCDI implements ITestCDI{
@Resource(name="java:/foo")
private String foo;
public String lookup() {
return foo;
}
public String lookup2() {
String ret = null;
InitialContext ic;
try {
ic = new InitialContext();
ret = (String) ic.lookup("java:/foo");
} catch (NamingException e) {
e.printStackTrace();
}
return ret;
}
}
-
3. Re: Re: testing with @Resource definition
jorgemoralespou_2 Sep 17, 2014 4:01 PM (in response to mlybarger)Hi,
As I guess you're using SY 2.0, and I do not know what's been added, I'll give you a non SwitchYard suggestion. Use a CDI @Alternative to inject another bean, with lookup2 as a provider for the String you want to lookup. This way you can bypass the problem that you are experiencing. Of course, if you can create a reproducer, just send it to this guys, so they can validate if it an error, or create a JIRA and attach the reproducer to it.
Hope it helps.
-
4. Re: Re: testing with @Resource definition
mlybarger Sep 17, 2014 4:22 PM (in response to jorgemoralespou_2)actually, i'm using FSW 6.0.0 (SY 1.1.0 GA).
I'm starting to believe that the weld being for the SY testing (SE) used doesn't have a ResourceInjectionServices instance available. I'd love to figure out how to add this service.
-
5. Re: Re: testing with @Resource definition
jorgemoralespou_2 Sep 17, 2014 5:10 PM (in response to mlybarger)Hi,
I guess that the SwitchyardRunner is the one that is hooking up things, and maybe you`re right and doesn't have that, or that it is a reduced service. I faced similar issues with @EntityManager but not sure if it was due to the fact that it doesn't run into an EE app server. As I said, In my case, I solved with with @Alternative and @Produces, having an alternative Bean that produced the EntityManager for me it worked.
If you get into a conclusion, please share, and if it as problem, raise the appropriate JIRAs.
-
6. Re: testing with @Resource definition
mlybarger Oct 1, 2014 1:39 PM (in response to jorgemoralespou_2)the problem is that CDIMixIn creates its own Weld instance that doesn't contain an instance of ResourceInjectionServices, thus, no @Resource injection occurs. I already had a modified CDIMixIn class that I was using to allow the testing of CDI beans directly in my unit tests per these notes:
Enhancement: CDI in SwitchYard Unit Tests
[SWITCHYARD-1645] CDI in SwitchYard Unit Tests - JBoss Issue Tracker
So, I grabbed org.jboss.as.weld.services.bootstrap.WeldResourceInjectionServices (copied into my project was easier), and then used that for weld to handle the @Resource injection.
My CDIMixInExt had the following:
Deployment deployment = createDeployment(resourceLoader, bootstrap);
// Set up the container
deployment.getServices().add(ResourceInjectionServices.class, new WeldResourceInjectionServices());
//JTAEnvironmentBean _jtaEnvironmentBean = new JTAEnvironmentBean();
//deployment.getServices().add(TransactionServices.class, new LocalArjunaTransactionServices(_jtaEnvironmentBean));
bootstrap.startContainer(Environments.SE, deployment);