I wanted to write test cased for testing my service using springjunit runner.
My service will call another service and transform its out put and send the response.
I thouhgt that server need to be up and running for calling the other service while running junit.
But I was told that spring junit doesnt need server to be running.
Spring container will do the magic it seems.
Am not pretty sure how this happens.
Can any one enlighten me with how spring container can act as server?
If its so silly quesiton,sorry for that.Thanks in advance
do you need server to run java.class , answer is no, untill unless if you have any ejb component to be called from your service, or you service need some external web service to
respond (here you may need to either mock this service to give mock data or run the service on server)
i have service which calls data access layer , sometimes service calls another service.
all you need to have spring context configuration in your test class
#ContextConfiguration({ "classpath:spring-context.xml", "classpath:otherservice-context.xml"})
#RunWith(SpringJUnit4ClassRunner.class)
#Component
public class TestJuint{
#Autowire
private otherService otherServiceImpl;
#Autowire
private service serviceImpl;
#Test
public void testDummy{
serviceImpl.addDummy(dummyObj);
}
}
suppose if you need to have another service from some other package then you might want to include its context file in context configuration, so that its bean reference will be in spring context while autowiring
Related
I have some end-to-end UI tests with WebDriver that use a remote wiremock instance, that I connect to in the following way:
#Configuration
public class WireMockConfiguration {
#Bean
public WireMock wireMock() {
return new WireMock("my-pyroxy.corp", 8080);
}
}
I have noticed that after tests finish, the wiremock server receives a shutdown request. The Wiremock::shutdown method is not marked with any annotation like #PreDestroy but Spring is still invoking it.
How do I stop it (apart from creating this wiremock client bean outside of the spring context?)
From the documentation of #Bean, I have learned this
To disable destroy method inference for a particular #Bean, specify an empty string as the value, e.g. #Bean(destroyMethod="")
I have a third party jar in my class path which has some services and DAO's developed on top of Spring 2.0.6 and Hibernate3.2.6. I need to call some of the services and daos.
Using ClassPathXmlApplicationContext I'm able to load the application context and able to access the services and daos. Both the service and dao are following ProxyFactoryBean pattern.
Problem comes when I'm accessing a DAO which has some single valued associations.When I'm accessing associated entity I'm getting lazy initialization problem.
To solve this problem:- If it is in my own application JAR I'll be able to change the fetch type into join or in DAOImpl method I could use Hibernate.initialize().
Is there a way to avoid this problem from the stand alone code itself? Or any other way to solve this issue without modifying applicationContext.xml and DAOImpl
You need to put the caller method into one single transaction.
If you have Spring transactional environment, you can put the call of the DAO services/repositories in your own service/method which is marked as #Transactional, or if transaction support is not enabled, but you still have spring support in your application, you can just use TransactionTemplate directly, provided by spring
#Autowire
private PlatformTransactionManager txManager;
TransactionTemplate template = new TransactionTemplate(this.txManager);
template.execute( new TransactionCallback<Object>(){
public void doInTransaction(TransactionStatus status){
// work done here will be wrapped by a transaction and committed.
// status.setRollbackOnly(true) is called or an exception is thrown
}
});
Otherwise you have manually handle transactionality by your own , depending on the technologies your app is using.
I have an application using Spring Integration where I have multiple handlers (strategies) for some service gateway methods, and I want the deployment launcher to be able to select which specific handlers are loaded. Since component scanning will pick up all of the handlers indiscriminately, I prefer to explicitly declare JavaConfig #Beans for them.
This works fine for the service objects themselves, but I can't find a way to load the service interface itself in Java without #IntegrationComponentScan. My current workaround is to include a "one-liner" XML file with an <int-gateway> tag and #ImportResource it, but I'd really prefer a more direct solution.
Is there any straightforward way in JavaConfig to tell Spring Integration to create a proxy service interface for a specific class?
GatewayProxyFactoryBean is for you.
This class is used to populate bean definition from <int:gateway> tag and from MessagingGateway annotation.
So, you can do like this:
#Bean
public GatewayProxyFactoryBean myGateway() {
GatewayProxyFactoryBean factoryBean = new GatewayProxyFactoryBean(YourServiceInterface.class);
factoryBean.setDefaultRequestChannel(gatewayRequestChannel());
return factoryBean;
}
What is the difference between registering a service as a normal service vs making it a ServiceFactory?
For example :
I have a normal osgi-component which I am making a service using service scr annotation
#Component
#Service
class Service1 implements Service1Interface {
...
...
...
}
Now, I have another osgi-component which I will be registering as service with ServiceFactory flag as true
#Component
#Service(serviceFactory=true )
class Service1 implements Service1Interface {
...
...
...
}
What exactly is the difference between these two? Is there any difference when they are registered in the container and in what scenario's should we go for a ServiceFactory?
In the former, there will be one instance of the component that will be used for all bundles that get the service. In the latter case, a new instance of the component will be created for each bundle that gets the service.
A service factory is useful if you need to track resources on a per using bundle basis.
I'm working on a very small application connecting to a MySQL database.
I'm trying to create table record but getting 'no transaction in progress'.
I have all the right stuff in place:
a service interface MyService and its implementation MyServiceImpl
I have annotated the service impl with #Service
In the controller I used the interface name for the field #Autowired MyService
I have the correct transaction configuration as it was originally generated by roo
There is a public method MyService.create(...) which MyServiceImpl implements
But,
When I remote debug and inspect the controller's myService field what I see is something like
com.some.package.services.MyService#12345 (and NOT something like $Proxy73) which to me is not right, because what should be autowired is the proxy not he target bean (which is what I think this is). If I'm correct then it makes sense that there is no transaction as the annotation would only kick in when invoking a public method annotated with #Transactional on a proxy.
Please tell me why is spring injecting the target bean in this setup.
Thanks
If you have AspectJ-enabled transaction management (<tx:annotation-driven mode="aspectj" .../>) application of transactions happens in-place in the same class, either during build (compile-time weaving) or on startup (load-time weaving).
No new classes are created (like when using cglib) and no proxies (like with ordinary interface-based AOP in Spring). Instead bytecode of MyServiceImpl was modified directly without you even noticing. Unfortunately the only way to see AOP is to decompile your classes. If you use javap -c MyServiceImpl you'll find plenty of references to Spring transaction layer.
If you are using Spring MVC, make sure to scan specific controller classes alone in servlet context file. Otherwise it will scan 2 times and transaction is not available on the application context.