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.

[dsklyut]

So I tried to be sneaky and by cannibalizing SyntheticContextBundleCreatingTransformer solve my issue.

i.e.
1. Create a new bundle
2. Add bundle imports for all domain bundles
3. Generate manifest
4. Save manifest and a template spring context xml definition with help of ArtifactStorageFactory
5. Add new bundle to plan

My thinking is that by doing bundle-import and keeping this new bundle in the scoped plan I will have visibility to all domain classes and able to piggy back on scoped plan support for hibernate/jpa.

Needless to say - first try ended up without success. Missed that ArtifactStorageFactory is in internal package .

Need to do more digging.

[Glyn Normington]

The ArtifactStorageFactory is a reasonable abstraction to use, so you could doctor the deployer bundle to export it, you could refactor it into a non-internal package, or you could add a helper class to the deployer bundle to enable you to access the function without using the interface directly.

You may care to raise a task against dm Server for us to consider making the interface available for non-deployer use, but we won't be able to fit that into 2.0 (which is in the process of being built for shipment).

[dsklyut]

I am attaching a fragment to deployer that will contain two interfaces to decorate Factory and ArtifactStorage and publish that new decorated Factory service.
I put them in com.springsource.kernel.install.artifact package for now.

To get that to work I think I would still need to modify launcher.bundles list or would need to do a refresh otherwise?

Also would I need to add that new service to import/export service list in com.springsource.kernel.userregion.properties ?

[dsklyut]

Alright,

To get my service visible in the userregion ended up modifying:

1. com.springsource.kernel.launch.properties
add my fragment to the list of launcher.bundles. no auto start as this is a fragment. Located before the com.springsource.kernel.deployer in the list.
Does location in the list matter?

2. /com.springsource.kernel.userregion.properties
add an entry to packageImports (because I ended up putting my code in a com.company.etc package)
add an entry to serviceImports to propagate service published from a fragment to the userregion.

That got me to the point of actually doing the work

btw. Got dm-server test framework to work with maven. Looks very promising! Now able to test without deployment to dm-server.

Any plans on documenting this framework a bit more? Got bit with placeholder value in com.springsource.kernel.userregion.properties.base Bundles. Framework replaced placeholders for test.config.properties but not for user region.