[Dev] Lots of changes

[Brett Wooldridge]

You need to update all of your projects after my latest check-ins.
Additionally, there are the following new modules you¹ll need to check-out:

org.ziptie.server.jnpserver
org.ziptie.server.c3p0
org.ziptie.server.jotm
org.ziptie.server.hibernate
org.ziptie.server.directory
org.ziptie.server.directory.device

Here¹s the big ticket items.

org.ziptie.server.jnpserver
> I¹ve integrated the JBoss standalone JNDI server.  It¹s currently configured
> as a ³local² JNDI, meaning in-process only (not listening on any port).  JNDI
> was ultimately needed to integrate the other services listed below.  The
> jnpserver OSGi bundle creates a JNDI compliant server instance, and therefore
> this bundle can be easily replaced with a bundle containing an alternate JNDI
> server with absolutely no change to any of the other bundles.

org.ziptie.server.jotm
> This is a Distributed Transaction Manager implementing the Java Transaction
> API (JTA).  The one in use here is the Java Open Transaction Manager from
> ObjectWeb.  What is this and why do we need it?  One of the pain points in the
> AlterPoint NetworkAuthority code was the rigid demarcation of database
> transactions.  What this meant was that if some method A had a (Begin
> transaction ... Execute SQL ... Commit) block, and later needed to call method
> B, that called method C, which needed to do SQL that was in the same
> transaction as A, we wound up having to parameterize all methods between A and
> C (or worse between A and Z) to pass A¹s Connection object all the way
> through.  Sometimes a mixture of Hibernate and classic SQL caused deadlocks.
> 
> A Transaction Manager provides for separation of transaction demarcation and
> DML execution.  It provides a ³global² transaction context (in our case
> thread-bound) to which any code may ³join².  It allows us to have a
> non-parametric model (much cleaner code), span transactions across Hibernate
> and classic SQL (!), and even to span transactions across databases (or
> machines!).
> 
> The JOTM OSGi bundle binds the Transaction Manager in JNDI under a well known
> name.  Hibernate looks for a JTA Transaction Manager bound under this name.
> It is therefore possible to replace the JOTM OSGi bundle with another bundle
> providing a different JTA Transaction Manager, for example the JBoss JTA,
> Bitronix JTA, or Atomikos JTA with absolutely no code change to any other
> bundle.

org.ziptie.server.c3p0
> Nothing to Earth shattering here. This is the most popular and feature rich
> JDBC connection pool around.  c3p0 reads it¹s configuration from
> c3p0-config.xml.  The c3p0 OSGi bundle binds the pooled DataSource in JNDI
> under a well known name.  Hibernate looks for a DataSource bound under this
> name.  As with the Transaction Manager, it is therefore possible to replace
> the c3p0 OSGi bundle with another bundle providing connection pooling, for
> example Apache DBCP, DBPool or SmartPool with absolutely no code change to any
> other bundle.  It is even possible to bind a simple unpooled DataSource into
> JNDI (for testing) and Hibernate won¹t know the difference.

org.ziptie.server.hibernate
> This is the Hibernate OSGi bundle provided by our Ukranian friends.  Some
> minor modifications were made.  First, the bundle no longer looks for the
> hibernate.cfg.xml file in the bundle¹s META-INF directory.  META-INF was a bad
> place for it because it¹s user editable and no user editable files should ever
> reside within the bundle itself (they will get replaced during an update).
> Second, the configuration is now such that it takes advantage of the
> Transaction Manager and connection pools provided by the above two bundles
> through JNDI lookups.

The Configuration Service Must Die
> In the course of reworking where the configuration files for these bundles are
> loaded from, I have come to the conclusion that the Configuration Service that
> was originally defined [by me] needs to die.  The service is created and
> registered by the bootstrap OSGi bundle and therefore the interface
> (IConfigurationService) resides in that bundle.  This means that any bundle
> wanting to ³find² their configuration data therefore has a dependency on
> org.ziptie.server.bootstrap.  Over the next day or so I will be eliminating
> this dependency.  I have already started doing so, and one change you might
> notice right away is that the ³conf² directory in the distribution is no
> longer present.  The configuration files are now deployed into the
> Œosgi-config¹ directory.  This location is pointed to by the
> ³osgi.configuration.area² Java system property.  This is where all modules
> should be looking for their configuration files, preferably in a private
> subdirectory at that location.  If you just create your configuration files
> and their private directories in the Œconf¹ project, everything will ³just
> work².

It is just way cool how well componentized the ZipTie server is turning out
to be.  Of course, componentization is something only a developer can love,
we still have to provide even cooler visible features to the community.
Still, modularity will pay us back in spades as we extend and refactor the
server over the course of time, and that will benefit everyone involved.

-Brett

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20070716/2c272723/attachment.html