i am creating a web service using 3rd party wsdl that helps me in getting a kind of notification. now i have to save that notification in DB and perform several other operations related to DataBase.
in My persistence.xml there are two persistence units as following:
<persistence-unit name="PU1" transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>jdbc/vsDS</jta-data-source>
<class>com.Response</class>
<class>com.Request</class>
<exclude-unlisted-classes>true</exclude-unlisted-classes>
<properties>
<property name="eclipselink.logging.level" value="INFO"/>
</properties>
</persistence-unit>
<persistence-unit name="PU2" transaction-type="JTA">
<provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
<jta-data-source>jdbc/vdDS</jta-data-source>
<class>com.LogRequest</class>
<exclude-unlisted-classes>true</exclude-unlisted-classes>
<properties>
<property name="eclipselink.logging.level" value="INFO"/>
</properties>
</persistence-unit>
till yet i have made a class named Service.java that have all functions i need to perform on DB as following:
public class Service {
private static Logger logger = Logger.getLogger(Service.class);
private EntityManagerFactory PU1;
private EntityManagerFactory PU2;
public Service(){
System.out.println("in service's constructer");
PU1=Persistence.createEntityManagerFactory("PU1");
PU2=Persistence.createEntityManagerFactory("PU2");
}
public void logSubRequest(String msg){
EntityManager em= PU1.createEntityManager();
try{
em.getTransaction().begin();
Request req=new Request();
req.setMessage(msg);
req.setStatus("Y");
em.persist(req);
em.getTransaction().commit();
}catch(Exception e){
logger.error("In logSubRequest="+e.getMessage());
e.printStackTrace();
}finally{
if(em.isOpen()){
em.close();
}
}
}
// there are several other methods of such kind that either persist entities or executeUpdate
}
My Question is: Am i going with standard approach to implement JPA with webservice or should i go with some other technology/method. kindly suggest and guide if i am doing any thing out of standard.
The combination of a Web services and JPA is often used, I see no reason to choose some other persistence mechanism. I'd recommend sticking with your current design until your requirements get more complex.
Larger applications where the equivalent of your Request object is more complex and the resulting business logic more challenging will add more layers of objects in order to control the structure and enable reuse.
I tend to think like this: The Web service interface is just one possible "way in" to the my business logic. So I might also have a RESTful service, or a JMS interface. Hence I tend to put my business logic inside an EJB, in simple cases a "No Interface" EJB. I focus on the EJB as a reusable piece of business logic that I can test in isolation. It will do all the JPA work. Then my Web service just uses that EJB to do its work. The EJB looks after the transactions so I don't need to write the transaction control code you have.
Related
I am trying to use WSO2 to schedule pooling data call every minutes to a REST API my business has and push that information to our centralize MQTT broker.
I've been reading the documents of the Streaming Integrator, Micro Integrator, Micro Gateway and API Manager and I cannot find any way to schedule REST API calls base on a defined time.
The point of this task is to push data from all our system into our centralize broker and add analyzing tool afterward to benefit from the data created by our systems that is only accessible by the system at this time.
Could someone give me a hint on what should be the right tools for this and maybe the link to some documentation about how to configure time base call if the software wso2 allowed it ?
You can create a WSO2EI scheduled task
You can define a cron job expression for timing and execute a sequence or an implementation class.
example:
<task name="SampleInjectToSequenceTask"
class="org.apache.synapse.startup.tasks.MessageInjector"
group="synapse.simple.quartz">
<trigger interval="5"/>
<property xmlns:task="http://www.wso2.org/products/wso2commons/tasks"
name="injectTo"
value="sequence"/>
<property xmlns:task="http://www.wso2.org/products/wso2commons/tasks"
name="sequenceName"
value="SampleSequence"/>
</task>
We have an application which needs to consume an external web service. To do this we have generated the set of Java artifacts from the WSDL via Maven using the wsdl2java goal provided by the cxf-codegen-plugin plugin.
We have written an integration test as part of our test suite which calls the real web service and everything works fine.
The code to integrate with the actual web service is then packaged into a set of JARs and used inside the front end application which needs to use the web service.
We are having an issue when the FE application uses the integration code. Exactly the same code is being executed by the FE application as is being used in our working integration test but the SOAP message which is ultimately generated is different between the two and the message generated by the actual application is incorrect.
The working SOAP request produced by our integration tests is:
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns12:ProcessUIRequest xmlns:ns10="http://zzz/yyyentityview/validation/"
xmlns:ns11="http://zzz/yyyview/search/list/"
xmlns:ns12="http://zzz/yyywebservice/v5/types/"
xmlns:ns2="http://zzz/yyyentityview/app/"
xmlns:ns3="http://zzz/yyyentityview/client/"
xmlns:ns4="http://zzz/yyyview/search/postcode/"
xmlns:ns5="http://zzz/yyyview/app/"
xmlns:ns6="http://zzz/yyyview/search/app/"
xmlns:ns7="http://zzz/yyyview/search/bank/"
xmlns:ns8="http://zzz/yyyview/uw/"
xmlns:ns9="http://zzz/yyybase/">
<ns12:ProcessUIRequest CallType="Submit" DisplayError="false"
IsAnonymous="false" IsCompactRequest="false" IsError="false">
<ns9:ModelData>
<ns9:TransactionData ApplicationReference="20000003CR3.00000003"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns5:QuoteLoadTxnDataVO" />
</ns9:ModelData>
<ns9:Activity ActionCode="QuoteLoad" ActionMode="Default"
ActivityCode="QuoteApplicationFull" ActivityMode="Default"
ActivityReference="" ActivityStatus="Inital"
ActivityTransaction="StartNewActivityAndLogOffUser"
CanProceedWithValidationsOutstanding="true">
<ns9:BusinessKeys>
<item>
<key>
<string>ADVREF</string>
</key>
<value>
<BusinessKeyVO KeyName="ADVREF" KeyValue="AVAGT01">
<BusinessKey KeyName="ADVREF" KeyType="Unknown"
KeyValue="AVAGT01" />
</BusinessKeyVO>
</value>
</item>
</ns9:BusinessKeys>
</ns9:Activity>
</ns12:ProcessUIRequest>
</ns12:ProcessUIRequest>
</S:Body>
</S:Envelope>
The POJO which is marshalled into that SOAP request is:
<tcp.ssgbase.BaseVO>
<modelData>
<transactionData class="tcp.ssgview.app.QuoteLoadTxnDataVO">
<applicationReference>20000003CR3.00000003</applicationReference>
</transactionData>
</modelData>
<activity>
<businessKeys>
<item>
<tcp.serializable__dictionary.BusinessKeyItem>
<key>
<string>ADVREF</string>
</key>
<value>
<businessKeyVO>
<businessKey>
<keyName>ADVREF</keyName>
<keyValue>AVAGT01</keyValue>
<keyType>Unknown</keyType>
</businessKey>
<keyName>ADVREF</keyName>
<keyValue>AVAGT01</keyValue>
</businessKeyVO>
</value>
</tcp.serializable__dictionary.BusinessKeyItem>
</item>
</businessKeys>
<actionMode>DEFAULT</actionMode>
<activityMode>DEFAULT</activityMode>
<activityTransaction>START_NEW_ACTIVITY_AND_LOG_OFF_USER</activityTransaction>
<actionCode>QuoteLoad</actionCode>
<activityReference></activityReference>
<activityStatus>INITAL</activityStatus>
<activityCode>QuoteApplicationFull</activityCode>
<canProceedWithValidationsOutstanding>true</canProceedWithValidationsOutstanding>
</activity>
<displayError>false</displayError>
<isAnonymous>false</isAnonymous>
<isError>false</isError>
<isCompactRequest>false</isCompactRequest>
<callType>SUBMIT</callType>
</tcp.ssgbase.BaseVO>
The SOAP request generated by the actual FE application is:
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Body>
<ns2:ProcessUIRequest xmlns:ns2="http://zzz/yyywebservice/v5/types/">
<processUIRequest>
<activity>
<actionCode>QuoteLoad</actionCode>
<actionMode>DEFAULT</actionMode>
<activityCode>QuoteApplicationFull</activityCode>
<activityMode>DEFAULT</activityMode>
<activityReference />
<activityStatus>INITAL</activityStatus>
<activityTransaction>
START_NEW_ACTIVITY_AND_LOG_OFF_USER</activityTransaction>
<businessKeys />
<canProceedWithValidationsOutstanding>
true</canProceedWithValidationsOutstanding>
</activity>
<callType>SUBMIT</callType>
<displayError>false</displayError>
<isAnonymous>false</isAnonymous>
<isCompactRequest>false</isCompactRequest>
<isError>false</isError>
<modelData>
<transactionData xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="ns2:quoteLoadTxnDataVO">
<applicationReference>
20000003ESF.00000018</applicationReference>
</transactionData>
</modelData>
</processUIRequest>
</ns2:ProcessUIRequest>
</soapenv:Body>
</soapenv:Envelope>
The POJO which is marshalled into that SOAP request is:
<tcp.ssgbase.BaseVO>
<modelData>
<transactionData class="tcp.ssgview.app.QuoteLoadTxnDataVO">
<applicationReference>20000003ESF.00000018</applicationReference>
</transactionData>
</modelData>
<activity>
<businessKeys>
<item>
<tcp.serializable__dictionary.BusinessKeyItem>
<key>
<string>ADVREF</string>
</key>
<value>
<businessKeyVO>
<businessKey>
<keyName>ADVREF</keyName>
<keyValue>AVAGT01</keyValue>
<keyType>Unknown</keyType>
</businessKey>
<keyName>ADVREF</keyName>
<keyValue>AVAGT01</keyValue>
</businessKeyVO>
</value>
</tcp.serializable__dictionary.BusinessKeyItem>
</item>
</businessKeys>
<actionMode>DEFAULT</actionMode>
<activityMode>DEFAULT</activityMode>
<activityTransaction>START_NEW_ACTIVITY_AND_LOG_OFF_USER</activityTransaction>
<actionCode>QuoteLoad</actionCode>
<activityReference></activityReference>
<activityStatus>INITAL</activityStatus>
<activityCode>QuoteApplicationFull</activityCode>
<canProceedWithValidationsOutstanding>true</canProceedWithValidationsOutstanding>
</activity>
<displayError>false</displayError>
<isAnonymous>false</isAnonymous>
<isError>false</isError>
<isCompactRequest>false</isCompactRequest>
<callType>SUBMIT</callType>
</tcp.ssgbase.BaseVO>
You can see that the structure of the two requests are different even though the code being executed in our integration JARs is exactly the same and the structure of the POJOs used to create the SOAP message is the same (barring one value). From the request, it looks to be like the request generated in the FE application is not picking up the correct WSDL and associated XSDs.
Our code to generate the correct service endpoint interface implementation is:
private <T> T createServiceObject(final Class<T> p_seiClass) throws ApplicationException {
try {
final Service serviceFactory = Service.create(new URL(wsdlLocation), new QName(targetNamespace, serviceName));
final SoapHandlerResolver handlerResolver = new SoapHandlerResolver();
handlerResolver.addHandler(new SoapMessageLoggingHandler());
serviceFactory.setHandlerResolver(handlerResolver);
final T service = serviceFactory.getPort(p_seiClass);
((BindingProvider) service).getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY,
"endpoint");
return service;
} catch (MalformedURLException e) {
throw new ApplicationException(ApplicationErrorCode.COMM_ERR_UNEXPECTED_ERROR, e);
}
}
After doing some debugging, I have noticed that the instance of the serviceFactory is different in the integration test and when we are running within the FE application.
In the integration test, the instance of the class (taken from the Eclipse debugger where we run the integration test using jUnit) is: 'JAX-WS RI 2.1.6 in JDK 6: Stub for ' and it appears to be of type 'SEIStub'.
When running within the FE application, the instance of the class is org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler. The FE application is hosted and executed on WebSphere Application Server.
So, my question is what could be happening when running in the actual FE application to cause the incorrect WSDL and XSD definitions to be picked up when marshalling the POJO into the SOAP request? I have spent a long time trying to debug this but to no avail.
The two soap request are different because, as you already said, the two serviceFactory is different and using different specifications 1.1 and 1.2.
My suggestion is that you configure your maven project to import the right jars on your test enviroment or update the jar on the container (the jar that create the serviceFactory). As I'm not familiarized with cxf-codegen-plugin I can't suggest more than that.
This suggestion was originally posted as a comment. The OP ask to put it as an answer.
I had this experienced when I was trying to write a client application and deploy it in Web Logic Server. You need to use exact version of java which is used by the server while creating the classes.
Soap request is created internally by JVM. If JVM is different while creating the classes and testing them and while consuming it on real time, SOAP will or may be different.
I am implementing a Spring MessageListener that is listening to a JMS Queue to process messages containing XML.
My bean ProposalSOAListener will be processing about 5 or more XML messages from the queue. My code is below.
Is there a way to specify different methods on this class to handle different XML messages?
public class ProposalSOAListener implements MessageListener {
public void onMessage(Message message) {
if (message instanceof TextMessage) {
try {
System.out.println(((TextMessage) message).getText());
} catch (JMSException ex) {
throw new RuntimeException(ex);
}
}
else {
throw new IllegalArgumentException("Message must be of type TextMessage");
}
}
} // end of ProposalSOAListener class
There's a bunch of architectural questions begged by your question. Do you want this mesasge listener to do the work, or hand it off to another component? Are there transactional considerations at play? Do you have memory constraints - i.e. do you want streaming based XML processing or not? Do
The good news is that you have a lot of the pieces to this puzzle available to you within Spring.
A simple next step would be to use Spring Object XML Marshalling (OXM), choose one of the techniques, and wire the marshaller into your listener bean.
See http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/oxm.html
Another technique would be to use the Spring ApplicationEvent interface, read the messages coming in off the queue and publish them internally to listeners of the specific types. That could be used in combination with the above object marshalling.
Last but not least, if this is SOAP web services - you can take a look at Spring WS, it uses the similar message containers to pull messages off the wire, marshall them, and invoke a spring ws endpoint (ie. the service interface that satisfies that interface contract).
http://static.springsource.org/spring-ws/sites/2.0/reference/html/server.html#d4e907
Spring Integration project is highly recommended for this kind of a problem. Essentially you will have to implement a jms inbound gateway to get your message in. You can then transform this to an object at this point, then route the message to the appropriate service-activator component, which can map to your instance and method.
I have JPA mapping to HSQLDB and persistence.xml reads as below:
<persistence-unit name="HMC">
<jta-data-source>java:hmc</jta-data-source>
<class>org.hmc.jpa.models.BloodGroup</class>
<class>org.hmc.jpa.models.ContactInfo</class>
<properties>
<property
name="hibernate.transaction.manager_lookup_class"
value="org.hibernate.transaction.JBossTransactionManagerLookup"/>
<property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect" />
</properties>
</persistence-unit>
But whenever application is deployed, it JBoss throws RuntimeException saying:
Specification violation [EJB3 JPA 6.2.1.2] - You have not defined a non-jta-data-source for a RESOURCE_LOCAL enabled persistence context named: ABC
I also have datasource defined in JBoss. Is there anything that I am missing in the configuration?
Regards,
Satya
if the transaction type of the persistence unit is JTA, the
jta-datasource element is used to declare the JNDI name of the JTA
data source that will be used to obtain connections. This is the
common case.
if the transaction type of the persistence unit is resource-local,
the non-jta-data-source should be used to declare the JNDI name of a
non-JTA data source.
hat is happening is that JBoss automatically scans and validates files named persistence.xml, since you are using spring to manage your beans, I guess you are not using EJB3.
What needs to be understood is if you want JBoss to control JTA transactions for you and if you want to use JBoss Transaction Manager, or if you just want to do JPA transactions, without JTA transaction control.
If you want to just use the JPA transactions and skip JBoss TransactionManagener, you can just rename your persistence.xml file to spring-persistence.xml (or whatever you like), and in spring-context.xml file you can change your entityManagerFactory to this:
<!-- JPA primary EntityManagerFactory -->
<bean id="entityManagerFactory" lazy-init="true"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"
p:persistenceUnitName="ExamplePU"
p:persistenceXmlLocation="classpath:/META-INF/spring-persistence.xml"
p:jpaVendorAdapter-ref="jpaVendorAdapter"
p:jpaDialect-ref="jpaDialect"
p:dataSource-ref="dataSource"/>
What happens is that by renaming the file JBoss won't validate it, since you are working outside of the EJB spec and not using any EJB beans, JBoss shouldn't be scanning this file anyways. And since you renamed it, you need to tell spring where it is and under what name.
I got it working by removing transaction-type="RESOURCE_LOCAL" and changing java:hmc to java:/hmc. But now my application has another problem whenever I try to persist.
It throws : java.lang.IllegalStateException: A JTA EntityManager cannot use getTransaction()
Can anybody tell me how to get a connection and start transaction in JTA mode?
Regards,
Satya
What does your Spring configuration for integration tests look like using an embedded h2 datasource and, optionally, JUnit?
My first try with a SingleConnectionDataSource basically worked, but failed on more complicated tests where you need several connections at the same time or suspended transactions. I think h2 in tcp based server mode might work as well, but this is probably not the fastest communication mode for a temporary embedded database in memory.
What are the possibilities and their advantages / disadvantages? Also, how do you create the tables / populate the database?
Update: Let's specify some concrete requirements that are important for such tests.
The database should be temporary and in memory
The connection should probably not use tcp, for speed requirements
It would be nice if I could use a database tool to inspect the content of the database during debugging
We have to define a datasource since we can't use the application servers datasource in unit tests
With the reservation that I do not know if there is any tool that can inspect the database, I think that a simple solution would be to use the Spring embedded database (3.1.x docs, current docs) which supports HSQL, H2, and Derby.
Using H2, your xml configuration would look like the following:
<jdbc:embedded-database id="dataSource" type="H2">
<jdbc:script location="classpath:db-schema.sql"/>
<jdbc:script location="classpath:db-test-data.sql"/>
</jdbc:embedded-database>
If you prefer Java based configuration, you can instantiate a DataSource like this (note that EmbeddedDataBase extends DataSource):
#Bean(destroyMethod = "shutdown")
public EmbeddedDatabase dataSource() {
return new EmbeddedDatabaseBuilder().
setType(EmbeddedDatabaseType.H2).
addScript("db-schema.sql").
addScript("db-test-data.sql").
build();
}
The database tables are created by the db-schema.sql script and they are populated with test data from the db-test-data.sql script.
Don't forget to add the H2 database driver to your classpath.
I currently include in a test-only springconfig-file as a datasource:
<bean id="database.dataSource" class="org.springframework.jdbc.datasource.LazyConnectionDataSourceProxy">
<constructor-arg>
<bean class="org.springframework.jdbc.datasource.SimpleDriverDataSource">
<property name="driverClass" value="org.h2.Driver" />
<property name="url"
value="jdbc:h2:mem:testdb;DB_CLOSE_DELAY=-1;MODE=Oracle;TRACE_LEVEL_SYSTEM_OUT=2" />
</bean>
</constructor-arg>
</bean>
<!-- provides a H2 console to look into the db if necessary -->
<bean id="org.h2.tools.Server-WebServer" class="org.h2.tools.Server"
factory-method="createWebServer" depends-on="database.dataSource"
init-method="start" lazy-init="false">
<constructor-arg value="-web,-webPort,11111" />
</bean>
Creating / dropping the tables can be done by using executeSqlScript when overriding AbstractAnnotationAwareTransactionalTests.onSetUpBeforeTransaction, or with SimpleJdbcTestUtils.executeSqlScript in an appropriate place.
Compare also this posting.
H2 is bundled with a built-in connection pool implementation. The following XML provides an example of using it as a Datasource bean without a need to introduce additional dependencies on DBCP or C3P0:
<bean id="dataSource" class="org.h2.jdbcx.JdbcConnectionPool" destroy-method="dispose">
<constructor-arg>
<bean class="org.h2.jdbcx.JdbcDataSource">
<property name="URL" value="jdbc:h2:dbname"/>
<property name="user" value="user"/>
<property name="password" value="password"/>
</bean>
</constructor-arg>
</bean>
The database will be shut down by calling a dispose method when Spring application context closes.
I think it's best to use your production DataSource implementation (only with different connection-string) for the unit-tests.
Anyway "failed on more complicated tests" doesn't give enough information for a more detailed answer.
(Self-ad : check this)