I haven't used Apache Axis since my 1.x days so I am little rusty here. My question is this.... How do I go about using the #Autowired annotation in my Apache Axis2 service endpoint class? Is this possible? I did some google searching and have yet to find anything conclusive. I am using Apache Axis2 version 1.5.1 and Spring 3.0.3. I just want to autowire up a simple DAO into my Web Service endpoint. I wouldn't think that would be so hard. I have already configured my applicationContext.xml and tested my DAO in a simple DBunit JUnit test case so it works fine. I can also Autowire up my Spring bean in my JUnit test. In my WAR I have configured my web.xml to use the org.springframework.web.context.ContextLoaderListener. This works fine and I can see when I deploy the war that the applicationCOntext is loaded up. Now how do I wire this up so I can use #Autowired in my Apache Axis2 service endpoint class?
Thanks for any help in advance!
Kyle
Resolved my own issue. Jsst needed to have my Service Endpoint class simply extend the SpringBeanAutowiringSupport class.
Related
Is there any additional configuration that needs to be done in order to enable CDI JTA Transactions using #Transactional annotation under CDI beans with Weblogic 12.1.3 server?
I have tried to just add the annotation into a service method, but EntityManager didn't recognize to be running under a transaction.
Is there any interceptor or something else that needs to be registered?
#JoshAment is right.
WebLogic 12.1.3 only partially supports Java EE 7 (it supports its four pieces: JPA 2.1, JAX-RS 2.0, JSON-P 1.0, WebSockets 1.0). But #Transactional is a part of JTA 1.2.
Right now only Liberty Profile is fully certified against Java EE 7.
The planned year-end WebLogic 12.1.4 is going to support it also.
Anyway, answering your question: just configured persistence.xml should be enough to use the #javax.transaction.Transactional annotation in your code.
// You may also consider to move away from Java EE 7 ;) then you would be able to freely choose whatever lib you want. I strongly believe that server itself should not provide anything except servlets.
I have a problem when I use both cxf and cxf-client together.
The cxf says that it can't find any services.
When I comment the configuration for the cxf-client the cxf finds the services.
The configuration for the servlet is the standard configuration.
The configuration for the client made from EU TIN service.
The two plugins works find seperately but not together.
Have anyone find a solution for this problem ?
Using grails version 2.3.7
Cxf version 1.1.4
cxf-client 1.6.1
I managed to get around the same problem by modifying CXF client plugin a bit. In WebServiceClientFactoryImpl modify creating JaxWSProxyFactoryBean as follows:
Bus bus = Holders.grailsApplication.mainContext.getBean("cxf") as Bus
JaxWsProxyFactoryBean clientProxyFactory = new JaxWsProxyFactoryBean(serviceClass: serviceInterface,
address: serviceEndpointAddress, bus: bus)
CXF plugin creates that 'cxf' bean which is of type org.apache.cxf.bus.spring.SpringBus. CXF client creates (by default) another bus which seems to break CXF web service. By using the same bus in CXF client the problem was solved.
I am using Apache Geronimo. I need a way to deploy an EAR application on an application server without starting the EAR module automatically.
When I deploy my EAR, it is automatically started. I need a way to specify, that it should only be deployed but not started.
Is there a way to do this?
In the past I've opened and closed gates to certain EJBs with the use of JMX.
The cool part:
100% Control your beans from outside using JConsole or your own JMX client.
The drawback:
Every bean instance has to be registered in the MBean Server which is not that cool as you are usually having multiple instances of the same bean.
The solution to this topic was having a #Singleton EJB working as a MBean/controller for all the instances of one EJB.
How does (JBoss) Shrinkwrap perform the deployment of a war file in the container when I use the #Deployment annotation in an Arquillian test?
As John said, it really depends on how container adapter is implemented (in particular the deployment automation bits). I case of WebSphere container adapter it's using SOAP admin client available from WAS, Glassfish stuff works through their REST api and so on.
This depends on your container, not all containers will do it the same way.
I am using OSGI with Glassfish 3.0.1.We use Jersey REST as the resource layer. We have lots of osgi services. we are planning to decouple them & deploy it in a cloud. One way we do this is by doing a http REST call. But we would like to do service to service call at the api level. One way to do this is by using DOSGI. But Glassfish 3.0.1 doesn't seem to support DOSGI. Any other suggestions?
I believe that Glassfish contains Apache Felix, which is a fully compliant OSGi Framework. Therefore you do not need explicit support from Glassfish in order to use a set of bundles that provide Remote Services (the name "DOSGI" is now deprecated). Indeed, this is kind of the point of OSGi!
Anyway the next obvious question is which Remote Services implementation to choose. I would advise you NOT to use CXF since it is too buggy and unmaintained. That leaves Eclipse ECF or Paremus RSA.
(Disclaimer: the Paremus implementation is commercial and I work for Paremus).