Wednesday, March 30, 2005

@Inherited won't work with Interface (JDK 1.5)

In my early code of SQLWarp, I created the annotation ConnectionInfo to be annotated on an interface, and I need it for an interface, not a class.


@Retention(RUNTIME)
@Inherited
public @interface ConnectionInfo {
public String driver();
public String url();
public String userID() default "";
public String password() default "";
}


The JDK doc says that @Inherited won't work with an Interface, so this is my work around to get annotation from the class that implements the interface which is annotated by @ConnectionInfo.


ConnectionInfo c = (ConnectionInfo)obj
.getClass()
.getInterfaces()[0]
.getAnnotation(ConnectionInfo.class);

Annotion-Based SQL Maps: Part II (JDK 1.5)

I show you the code sample from iBatis SQL Maps 2.0 last post.
I continue realizing the idea:


public interface MyDAO {

@Sql(expr="
SELECT
ADR_ID as id,
ADR_DESCRIPTION as description,
ADR_STREET as street,
ADR_CITY as city,
ADR_PROVINCE as province,
ADR_POSTAL_CODE as postalCode
FROM ADDRESS
WHERE ADR_ID = ?value
")
public Address getAddress(int value);

}


Q: We need code genraotor to create a class from the SQL expression.
A: MiddleGen could help.
Q: Implement the above method using a proxy class, a runtime class-wrapper.
A: CGLIB or Javassist.
Q: Need parsing parameters in the SQL expression, and bind to method's parameters.
A: I think this can be done using in-house parser, or hacked from iBatis SQL Maps.

Tuesday, March 29, 2005

My Draft Notes on Class Versioning, O/R Mapping and Separation of Concerns

Review Rashid's works:


class Person<2.0> {
private String firstName;
private String surName;
}

class Person<1.0> {
private String firstName;
private String lastName;
}


Next step?
Separate, then later weave.
this means
+ We seperate when design --> yield easier design
+ We weave when use --> it must be complex enough to serve all business logics
+ Modification to EJB3 should be great (it's same to OODBMS, dont care RDBMS layer)

Why?
+ It's not possible to change all RBMS invesment to OODB
+ It seems that implementing virtual databases over the tranditional RDBMs is better
+ A virtual database (in my case OR/mapping - Hibernate, Ejb3) can be fully applied with AOSD
+ class versioning schema manager (Rashid 2002-2004)
+ annotation
+ concern
+ data alignment concern

This is an idea for separating Object and Relation concerns:


// teacher data concern
@Entity("Teacher", "1.0")
class Teacher {
private int teacherID;
private String firstName;
private String lastName;
}

@Entity("Student", "1.0")
class Student {
private studentID;
private firstName;
private lastName;
}

// separate advisor concern
@Entity("Teacher", "2.0")
class Advisor {
private List adviseeLists;
}

// separate advisor concern
@Entity("Student", "2.0")
class Advisee {
private Advisor advisor;
}

Teacher t = entityManager.load(Teacher.class,
new Integer(1));
Advisor a = versioningManager.morph(t,
Advisor.class);




This is a new idea for field substitution
How the developer access this code?
possible answer: IoC?


@Version(2.0)
class Student {
@Substitute(version="1.0", name="lastName")
private surName;
}

class StudentDAO {

public Student findById(int id) {
// codes go here ...
}

@Conform("th.ac.sut.ent.Student", "2.0")
public static void main(String args[]) {

Student s = new StudentDAO().findById(10);
// not found, throw exception
System.out.println(s.getLastName());
// should be ok
System.out.println(s.getSurName());
}
}

Monday, March 28, 2005

Idea on Annotaion-based iBATIS SQLMaps (JDK 1.5)

This is my proposal for hacking iBATIS SQLMaps to be annotation-based version.
After looking at the example, I saw the following code:


<select
id="getAddress" parameterClass="int"
resultClass="examples.domain.Address">
select
ADR_ID as id,
ADR_DESCRIPTION as description,
ADR_STREET as street,
ADR_CITY as city,
ADR_PROVINCE as province,
ADR_POSTAL_CODE as postalCode
from ADDRESS
where ADR_ID = #value#
</select>


can be changed to annotation attaching on a method of a Java interface.
#value# should be able to bind with the parameter, like this:


@Sql("select ... ")
public Address getAttress(int value);


Proxy-based AOP is enough for this implementation. A proxy class can be geneated at runtime, using the technique I proposed in SQLWarp.

later...

Wednesday, March 23, 2005

Refactored Suranaree.Galvanium (.NET/Java)

It is completely my fault trying to integrate some GUI features into my Galvanium framework. Now I refactor all GUI-related features out of the framework, and upgrade its dependencies (IKVM from 0.8 to 0.12, and lastest Hessian 3.0.8). The new binary will be posted soon. This version will be 1.0 M3.
Features

  • At least 250% faster than XML Web Services
  • Lightweight Protocol based on Hessian
  • Seamless Integration of J2EE objects and .NET GUI
  • Direct .NET/Java type mapping
  • Display/Edit Java objects in Databinding Controls of .NET
  • Works behind Firewall
  • Support Mock Object via ClientProxyFactory

Components
  • ClientProxyFactory
  • BeanDescriptor
  • BeanCollection

with additional 2 samples.

Tuesday, March 22, 2005

Annotion-Based Embedded SQL (JDK 1.5)

I wanna learn how to create and use annotations in JDK 1.5, so I got some idea from voruta.sf.net.
Voruta is an embedded SQL framework using Javadoc's style annotation. Based on the same idea, but mine is more dirty :), I implement data access framework for embedding SQL statement with JDK 1.5 annotation. I call it the SQLWarp. You can download and try it here.

UIB dbExpress Broker Patch for InstantObjects (Delphi)

I've submitted the patch to include UIB dbExpress driver for InstantObjects DBX broker to InstantObjects dev team.
It supports UIB Firebird15 driver, which is compatible with Firebird 1.5.x.
I tested this patch with Firebird 1.5.2 for Windows.

You can download the patched version from here (InstantDBX.pas) and replace it to [Brokers/DBX/InstantDBX.pas] under the InstantObjects folder.