plans within plans and scopping

[dsklyut]

Hi,

I have been playing around with plan referencing other plans.

I was able to deploy a plan that references another plan. So far so good.

I also experimented with trying to see what happens when either outer or inner plan are scoped. One note: inner plan atomic setting did note make a difference in behavior.

1. Outer scoped = true, Inner scoped = false
Both plan deploy. Outer plan artifacts of type = bundle are deployed within synthetic.context. Inner plan artifacts = bundle are deployed outside of that synthetic.context.
This means that services published by outer plan are never seen by inner plan.

2. Outer scoped = true, Inner scoped = true
Outer plan is deployed with synthetic.context. Inner plan scoped attribute looks to be ignored. Plan deployed as unscoped plan. Services from outer plan are not visible to inner plan.

3. Outer scoped = false, Inner sopped = false
Deploys fine. Services are visible across (cause nothing is scoped). Hibernate usage is broken understandably ( class not visible error).

4. Outer scoped = false, Inner sopped = true
Deploys fine. Services from outer plan are visible in inner plan. Issues with hibernate (understood why).
Inner plan create a synthetic.context bundle, but bundles from inner plan are not prefixed/rewritten with synthetic.context prefix in BSN.
Also inner plan synthetic.context bundle is generated without a version in it.

Usually when plan is scoped, I see <plan.name>.plan-<plan.version>-<plan.name>.plan-synthetic.context,
but with inner scoped plan it ends up:
<plan.name>.plan-synthetic.context

We are trying to partition up our application vertically and then horizontally. We have seen some success with Slices.
We have developed a set of common components than includes a host web app and one slice (A).
We are now in process of developing a second slice (B) that will depend on some components of A and transitively on common components.

It would have been a great feature to have plans within plans in this situation where scope of the plan is determined by the outermost plan.
Scope would allow us to use ORM tooling and create composite applications from re-usable set of plans.

I heard that plans within plans are not something planned for 2.0 release at SpringOne.

So now to the questions:
Given that I have a set of "common" bundles, and multiple combination or sliced application (that themselves made up of number of bundles), what would be an approach to deployment? Restriction is usage of Hibernate or any ORM for that matter across slices, i.e. Slice B code can extends Slice A code for entity persistance. This forces us to use scoped plans.
I am planning to do multiple plans for each possible combination. Thankfully we won't have more than 5-6 combination of plans initially.

[Glyn Normington]

I'm sorry you've hit this problem. It looks like some gaps in our testing.

Plans can reference plans in 2.0, but some combinations have restrictions. One restriction is when a scoped plan refers, possibly transitively, to another scoped plan. I can't remember whether we intended to fail this case or cause the outer scope to include the inner scope, but either way you won't get a properly nested scope.

However, the other combinations should work with the scoped plan including all of its own contents and the contents of any plans it references (transitively) in its scope and synthetic context.

Therefore I think you have found at least one defect. Please would you be kind enough to raise a JIRA for each distinct failing case you believe should work and which you care about. I would say that there are two defects based on your findings above: a scoped plan referring to an unscoped plan and an unscoped plan referring to a scoped plan.

If you are able to attach trivial binary testcases to the defects, that would be a help.

[dsklyut]

Glyn

Thank you for response. I submitted defect for issue 1 https://issuetracker.springsource.com/browse/DMS-2156.

But I wanted to understand limitations of scoped plan referencing another scoped plan. Would it make sense in that case for outer plan scope to win out?

[Glyn Normington]

Thanks for raising the issue.

As for a scoped plan nested in another scoped plan, I haven't yet decided on the best semantics so I'm going to discuss it with the others later and report back here.

If we want to make that case succeed, then allowing the scope of the parent plan to include the child plan is one reasonable solution. Another solution is to give the child plan a completely separate scope than the scope of the parent plan.

However, with RFC 138 nested frameworks in mind and the possibility of supporting "sub-scopes", i.e. scopes properly nested within other scopes, my personal preference would be to fail the deployment of a scoped plan nested in another scoped plan. This gives us a backward compatible way of introducing sub-scopes in the future.

If we allowed the parent scope to include the child plan, then introducing sub-scopes would cause compatibility problems. For example, packages exported and services published in the child plan would cease to be visible in the parent plan.

If we gave the child plan a separate scope than the scope of the parent plan, then introducing sub-scopes would cause different compatibility problems. For example, package imports and service references in the child plan which are not satisfied by the child plan would cease to bind to the global scope if they were satisfiable in the parent scope.

[dsklyut]

Glyn,

Very interesting points. Did not even consider dm server supporting nested frameworks.
I would be happy for now with a outer scoped plan that references number of inner unscoped plans as dependencies. I would expect such configuration to result in a single scoped "application" where all plans can resolve packages/services across defined dependencies.

[Glyn Normington]

Agreed.

The consensus here is to fail scoped plans (transitively) nested within scoped plans.