Re: Maven based build and refactoring

From: "Atri Sharma" <atri(dot)jiit(at)gmail(dot)com>
To: "'Sebastian Hennebrueder'" <usenet(at)laliluna(dot)de>, <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Maven based build and refactoring
Date: 2012-03-25 17:32:20
Message-ID: 4f6f56ae.8706440a.6252.ffffb855@mx.google.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

From: pgsql-jdbc-owner(at)postgresql(dot)org
[mailto:pgsql-jdbc-owner(at)postgresql(dot)org] On Behalf Of Sebastian Hennebrueder
Sent: 25 March 2012 21:47
To: pgsql-jdbc(at)postgresql(dot)org
Subject: [JDBC] Maven based build and refactoring

Hello to all,

actually I only wanted to have a look which JDBC 4 methods had been missing
and provide a helping hand to implement those.

The reason is that Hibernate requires now JDBC 4 and Hibernate is the
underlying JPA provider in the JBoss application server as well. I prefer
PostgreSQL over other open source database server, so JDBC 4 is an absolute
requirement.

I found the building mechanism a little bit special and played with
refactoring the code such that a Maven build could work.

I split the code into common and jdbc version specific versions and found
clean ways to solve the version, minor and major version infos, exception
factories and logger control but reached now a point where the refactoring
would require deeper code changes.

Before I spent time doing this, I would like to know if there is any
interest in this.

Here is my plan:

separation of the projects into

common (all which is not in the other packages)

jdbc3 (contains generated classes)

jdbc3g (contains generated classes)

jdbc4 (contains generated classes + jdbc4 only code)

common-test (all tests)

Version information are loaded from property files which can be replaced
during build time. The Driver delegates to a DriverVersion class in the
common module which provides the version information.

An exceptionFactory in the common module provides the "unimplemented"
factory method for exceptions.

As there are classes in common which references classes in jdbc(3 | 3G | 4)
the code needs to be decoupled using interfaces. The lack of interfaces and
the wildly use of inheritance instead of composition is the biggest obstacle
to decouple modules.

This is the bigger change, I am about to do.

I would introduce a Service registry, which can create providers for various
interfaces. The driver could register on start up (static block) . Here is a
conceptual piece of code:

class ServiceRegistry{

static Map<Class,Provider> interfaceProviderMap

…

public static Provider getProvider(Class aClass){ … }

}

The code in the class PGObjectFactory in the method could then be changed
from

private Object loadSimpleDataSource(Reference ref)

{

PGSimpleDataSource ds = new PGSimpleDataSource();

return loadBaseDataSource(ds, ref);

}

to

private Object loadSimpleDataSource(Reference ref)

{

Provider provider =
ServiceRegistry.getProvider(PGSimpleDataSourceInterface.class);

PGSimpleDataSourceInterface ds = provider.create();

return loadBaseDataSource(ds, ref);

}

--
Best Regards / Viele Grüße

Sebastian Hennebrueder
----------------------

Hi Sebastian,

I am a student and I am planning to work on implementing the missing parts
of JDBC 4 as my GSoc 2012 project.I have already started discussing with
Dave Krammer for this.

It would be really helpful for me if senior hackers like yourself can assist
me in this ambitious project of mine.

Regards,

Atri

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Dave Cramer 2012-03-25 22:39:12 Re: Maven based build and refactoring
Previous Message Sebastian Hennebrueder 2012-03-25 16:16:34 Maven based build and refactoring