14 Aralık 2010 Salı

How to generate JAX-WS Client classes that implement the Serializable interface

The serializable interface vanishes when client side stubs are generated using jax ws..

Here is a solution to keep serializable interface:

There is also a plugin solution:

However, the binding file i previously used for XMLGregorian Calendar vs Date issue worked for that, too.. So, i stick to it:
For details, please see the previous post:

a correction may require in wsdl files if this error comes up:
[ERROR] XPath evaluation of "wsdl:definitions/wsdl:types/xsd:schema" results in too many (8) target nodes

<xsd:schema>
<xsd:import namespace="http://..." schemaLocation="http://...Service?xsd=1"></xsd:import>
</xsd:schema>
<xsd:schema>
<xsd:import namespace="http://..." schemaLocation="http://...Service?xsd=2"></xsd:import>
</xsd:schema>
<xsd:schema>
<xsd:import namespace="http://..." schemaLocation="http://...Service?xsd=2"></xsd:import>
</xsd:schema>

edit as follows, so it contains exactly one xsd:schema element:

<xsd:schema>
<xsd:import namespace="http://..." schemaLocation="http://...Service?xsd=1"></xsd:import>
<xsd:import namespace="http://..." schemaLocation="http://...Service?xsd=2"></xsd:import>
<xsd:import namespace="http://..." schemaLocation="http://...Service?xsd=2"></xsd:import>
</xsd:schema>

13 Aralık 2010 Pazartesi

persistence using jpa

I have one database, but the atomicity of transactions is large. In other words, many entities must be manipulated in one transaction. Therefore, the design is something like that:
  • a general superclass entity that holds shared stuff amongst all other entities that are subject to be persisted.
  • an entity manager class that is responsible for creation of emf and em.
  • a general dao for the superclass mentioned above, to accomplish shared, general persistence tasks (crud operations - create, retrieve, update, delete ). The entity class type and an entity manager is injected to this dao.
  • specific dao classes for entities that needs operations other than crud. Something to note down is that since transaction management must be done in an upper layer in this case, no begin, commit or rollback transaction operation appear at dao (persistence) layer.
// general superclass
@MappedSuperclass
public class MyBean implements Serializable {

@Id
@GeneratedValue(strategy = GenerationType.TABLE)
private Long id = -1L;
// ...
}

//////////////////////////////////////////////////////////////
// a specific class
public class SpecificBean extends MyBean {
// ...
}

//////////////////////////////////////////////////////////////
// entity manager class
public class MyEntityManager {

private static final String PERSISTENCE_UNIT = "MyPU";

@PersistenceUnit(unitName = PERSISTENCE_UNIT)
private EntityManagerFactory emf;

public EntityManager getEm() {
if (emf == null) {
emf = Persistence.createEntityManagerFactory(PERSISTENCE_UNIT);
}
return emf.createEntityManager();
}
}

//////////////////////////////////////////////////////////////
// general dao for superclass MyBean
public class MyBeanDao {

private Class clazz;
protected EntityManager em;

public MyBeanDao(Class clazz, EntityManager em) {
this.clazz = clazz;
this.em = em;
}

public void create(MyBean bean) {
em.persist(bean);
}

public MyBean retrieve(Long id) {
return (MyBean) em.find(this.clazz, id);
}

public void remove(Long id) {
MyBean bean = retrieve(id);
if (bean != null) {
em.remove(bean);
}
}

public MyBean update(MyBean bean) {
MyBean updated = em.merge(bean);
return updated;
}

public void closeEm() {
em.close();
}

public void initTransaction() {
em.getTransaction().begin();
}

public void finishTransaction() {
em.getTransaction().commit();
}

public void rollbackTransaction() {
em.getTransaction().rollback();
}
}

//////////////////////////////////////////////////////////////
// specific dao classes
public class SpecificDao extends MyBeanDao {

public SpecificDao (EntityManager em) {
super(SpecificBean.class, em);
}
// extra methods
}

//////////////////////////////////////////////////////////////
// sample call

MyEntityManager mem = new MyEntityManager ();
EntityManager em = mem.getEm();

SpecificDao dao = new SpecificDao (em);

dao.initTransaction();
// do something
// ....
dao.finishTransaction();



more effective solutions may exist.. this is just a sample design..

11 Aralık 2010 Cumartesi

object cloning in java

java objects are manipulated via reference variables, there is no way to copy an object in java directly.. clone() method of Object class is used to provide a standard copying mechanism. clone() returns an Object, so dont forget to recast..
There is also the shallow copy - deep copy issue to deal with.. In shallow copy only the surface portion of the object is copied, as in the case of Arraylist s overrided clone().
A property of shallow copies is that fields that refer to other objects will point to the same objects in both the original and the clone. (http://javatechniques.com/blog/faster-deep-copies-of-java-objects/)
Copying the object entirely is the deep copy..
In order to make a class with the ability of deep copying itself:
  • default clone() implementation throws CloneNotSupportedException (if class is not implementing Cloneable interface)
  • implement Cloneable interface
  • make overrided clone() implementation public and do super.clone() (as in all Collections clone() methods)
  • Object s clone() only makes shallow copy, so write your implementation for a deep copy..

  • public class SampleClass implements Cloneable {
    ...
    public Object clone() throws CloneNotSupportedException {
    return super.clone();
    }
    }

    Serializing and reconstructing when the object is extremely complex, is also a solution to deep copying problem.. Besides, in http://javatechniques.com/blog/faster-deep-copies-of-java-objects/, the code presents a faster way of making deep copy..

    http://www.go4expert.com/forums/showthread.php?t=5424
    http://www.jguru.com/faq/view.jsp?EID=20435 (this is the solution i used, since i have complex serializable objects..)

    7 Aralık 2010 Salı

    WS-SecureConversation and WS-Atomic Transaction

    In our project, we needed a way to provide security in an efficient way and WS-Security is a bit heavy and inefficient.
    We have found a great WSIT tutorial and decided to use WS-SecureConversation which is almost twice faster than WS-Security according to our tests (tests carried out calling a simple web service 10000 times).
    The link to tutor: http://download.oracle.com/docs/cd/E17802_01/webservices/webservices/reference/tutorials/wsit/doc/index.html
    and pdf version is at http://download.oracle.com/docs/cd/E17802_01/webservices/webservices/reference/tutorials/wsit/doc/WSITTutorial.pdf

    We also need to manage transactions and worked on WS-AT by using the sample at http://wiki.open-esb.java.net/Wiki.jsp?page=HTTPBCWSAtomicTransaction which is linked from http://wiki.open-esb.java.net/Wiki.jsp?page=UsingWSTransaction

    However, our client is not a j2ee, so WS-AT is not appropriate for such an environment (http://java.net/jira/browse/WSIT-526)

    Now, our direction is to handle transactions in bpel processes themselves.. i will write about it, when we discover something.. a starting point : http://wikis.sun.com/display/JavaCAPS/Transactionality+-+BPEL2.0+SE
    And, a summary of the wsit tutorial i mentioned above, will be one of the next posts..

    25 Ekim 2010 Pazartesi

    error: PSQLException: FATAL: sorry, too many clients already

    the error is:

    aused by: org.hibernate.exception.GenericJDBCException: Cannot open connection
    at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:103)
    at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91)
    at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
    at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:29)
    at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:426)
    at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:144)
    at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:119)
    at org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:57)
    at org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1326)
    at org.hibernate.ejb.TransactionImpl.begin(TransactionImpl.java:38)
    ... 64 more
    Caused by: org.postgresql.util.PSQLException: FATAL: sorry, too many clients already
    at org.postgresql.core.v3.ConnectionFactoryImpl.readStartupMessages(ConnectionFactoryImpl.java:464)
    at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:112)
    at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:66)
    at org.postgresql.jdbc2.AbstractJdbc2Connection.(AbstractJdbc2Connection.java:125)
    at org.postgresql.jdbc3.AbstractJdbc3Connection.(AbstractJdbc3Connection.java:30)
    at org.postgresql.jdbc3g.AbstractJdbc3gConnection.(AbstractJdbc3gConnection.java:22)
    at org.postgresql.jdbc4.AbstractJdbc4Connection.(AbstractJdbc4Connection.java:30)
    at org.postgresql.jdbc4.Jdbc4Connection.(Jdbc4Connection.java:24)
    at org.postgresql.Driver.makeConnection(Driver.java:393)
    at org.postgresql.Driver.connect(Driver.java:267)
    at java.sql.DriverManager.getConnection(DriverManager.java:582)
    at java.sql.DriverManager.getConnection(DriverManager.java:154)
    at org.hibernate.connection.DriverManagerConnectionProvider.getConnection(DriverManagerConnectionProvider.java:110)
    at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:423)
    ... 69 more


    see http://stackoverflow.com/questions/220374/do-i-have-to-close-every-entitymanager