Spring Webservices

I've heard about Spring Webservices for quite sometime now, but didnt really look into it until yesterday. Here is an example of a POJO that is annotated with @Endpoint annotation.

@Endpoint
public class PurchaseOrderEndPoint implements PurchaseOrderWebService {
 private static final Log LOG = LogFactory.getLog(PurchaseOrderEndPoint.class);

 /**
  * Process purchase order
  *
  * @param request purchase order request
  * @return
  */
 @PayloadRoot(localPart = PURCHASE_ORDER_REQUEST,
namespace = PURCHASE_ORDER_NAMESPACE)
 public PurchaseOrderResponse processPurchaseOrder(PurchaseOrderRequest request) {
     LOG.info("Received purchase order request");
     PurchaseOrderResponse resp = new PurchaseOrderResponse();
     resp.setPurchaseOrderNumber("DEBUG MESSAGE");
     return resp;
 }


 /**
  * Check for order status
  *
  * @param req order status enquiry request
  * @return
  */
 @PayloadRoot(localPart = PURCHASE_ORDER_STATUS_ENQUIRY_REQUEST,
namespace = PURCHASE_ORDER_NAMESPACE)
 public PurchaseOrderStatusEnquiryResponse checkPurchaseOrderStatus(PurchaseOrderStatusEnquiryRequest req) {
     LOG.info("Received purchase order status enquiry request");

     PurchaseOrderStatusEnquiryResponse rsp = new PurchaseOrderStatusEnquiryResponse();
     rsp.setStatus(PurchaseOrderStatus.RECEIVED);
     return rsp;
 }
}

So thats multiple payload handler in one POJO class, instead of one endpoint per payload handler like what I used to do at work.

Extending Stripes

I'm currently working on a project that involves:
1. Multiple application roles
2. Multiple application views (or pages, if you'd like to call it that way)
3. Based on the view & the role, display the underlying model differently (either as editable field, or as label - i.e. non editable field.. or dont display at all).


The quick & dirty solution - to write the logic in the view. i.e. something like:


ifuserinrole role="Admin"
// display as editable field
ifuserinrole


and so on...

But that is ugly. The view decides the security setting.
I discussed this issue with my colleague, and we came up with an interesting idea. Basically, it involves having a separate security module that can be queried. Given the page, the role, and the field name, decides whether the field is editable/readable/hidden.

So I spent half a day today to write a prototype for this extension. It has been quite a while since I get excited about the code that I write.... so here is the idea...

1. The configuration is to be read on application start up. It will be nice if the config can be:
- changed during runtime
- have multiple implementation (file based / database based)

2. Configuration is available as Dependency Injectable bean, so that multiple views can use the configuration easily

3. Extend the current presentation framework to consult the configuration (using dependency injected configuration!), and display accordingly


I have achieved all three, except:
- changing configuration during runtime
- using database based configuration setting


So I'm quite a happy chap now.. :)

Hibernate + Oracle + Blob = bug

I've just recently start to use Hibernate session's merge method. Who would have thought that it has a major bug on session merging hibernate object that has blob field?

i.e. for the following hibernate class:

@Entity
@Table("table")
public class MyClass{

    @Lob
   @Column(name="a_column")
   private Blob aBlobColumn;
}

when you assign 'aBlobColumn' a value, and do session merge, the returned object will have aBlobColumn as null. That is bizarre. The same wont happen if you do the normal session save followed by session.get....

Apparently it is a known bug, dating from 2004 (or maybe before that!!).... 5 years ... and they havent fixed it... sigh......

Well.. of course there's a workaround.... which is quite stupid.... just populate the returned object with whatever you save..... but that is... ugly......... and what if the value has been nulled in the first place (in the database) ?.... that is going to screw things....
(you can argue , to have row versioning.... but you cant argue that it is a bug)..