What are public extension points of deployment chain?

[dsklyut]

Hi,

I am in a situation right now where I need RFC 143 (jpa in osgi) like functionality in next few weeks. Looked around gemini/aries/eclipselink/glassfish and none of those provide what I need or provide much useful .

I started planning for an extender bundle, but got to thinking maybe extending/plugging into dm server deployment pipeline would be a better choice?

I would like to have a single session factory to repositories can be shared within my composite application. Application is deployed as a scoped plan (composed of other plans).

It boils down to:
1. Inspect each bundle to find hibernate/jpa config
2. Make sure that all bundles in plan are processed
3. Merge configuration
4. Create session factory, making sure to reset classloader
5. publish session factory service and transaction manager

So the question is two fold:
1. Would something like this benefit of having access to dm-server internals
2. if 1 == yes, what are the proper hooks (transformers, listeners, etc).

Thanks in advance!

[Glyn Normington]

I don't know whether you could achieve what you want using standard dm Server JPA support, so I'd be interested to know why you think that isn't sufficient for your application.

But, if you need to, yes, you could probably get a lot of benefit if you are willing to depend on dm Server internals.

To understand the overall structure of the deployment pipeline, take a look at the Plumber class which builds the pipeline. Each artifact which is explicitly deployed (rather than provisioned in order to fulfill a dependency) is passed through the deployment pipeline. The artifact is represented as a tree. In the case of plans, this tree is "resolved" fairly early on so that each member of the plan is a child of the plan node.

The main extension point of the deployment pipeline is obtained by publishing a Transformer service in the service registry. A Transformer is passed the top-level Tree of InstallArtifacts which is being deployed. It can traverse the tree and make fairly arbitrary modifications, such as adding nodes (perhaps you might want to add a bundle).

The main consideration for Transformers is that of interaction with other Transformers. Transformers are driven in the natural order of their services which is determined by service ranking and service id. The usual ordering gotchas apply: take care if you must be first or must be last in the ordering as you may end up conflicting with another Transformer that believes it has the same requirement.

The Plumber class is defined in the com.springsource.kernel.deployer.core.internal package and the Transformer interface is defined in the com.springsource.kernel.install.pipeline.stage.tra nsform package, both of which belong to the kernel's deployer project.

Please feel free to post back here with more questions We'll be able to give you a bit more attention once we've shipped 2.0.

[dsklyut]

Glyn,

Thank you very much for pointers.

The major reason for trying this route is a vertical partitioning of our application(s). I have knowledge about just one (1) domain bundle at the core tier. Other applications/components can extend/contribute new entities based on the composition of the final plan deployment. So before we can use any of the jpa/hibernate/orm services, we need to merge all of the possible persistent units contributed by domain bundles.

This can potentially be resolved by restructuring the domain objects hierarchies and using components vs. entities for relationships this way each application can still use local session factory for its set of entities. Key word is "potentially"

I will post back with my approach.

[Glyn Normington]

I see, thanks. Another complex application! I'll stick to middleware...

[dsklyut]

Well said

[Glyn Normington]

I forgot to mention that the majority of the Transformer services are defined in the deployer Spring configuration file (deployer-context.xml, near the top), although the odd one is defined elsewhere e.g. by the web layer.