Questions about .par concept

[Beta User]

Hello everybody

I have some questions and thoughts about the .par file concept.

As far as I understood, the par file gives me - among others - the possibility to
- deploy many jar files as one (similar to a war file with jars in lib subfolder)
- introduce some kind of a "group" scope in the OSGi world (references between bundles in the par are tried to be satisfied internally primarly)
- choose where I have depending bundles: in my par or already installed as separate bundle in the OSGi environment
Is that correct?

Assuming it is correct, the following questions came up in my mind:
1) Is it possible to deploy the same par file multiple times in the same OSGi environment? I assume yes, as long as they have differing versions
2) Can "pure OSGi bundles" (not packaged in a par) have dependencies to bundles within a par? (That is: Are bundles contained in a par publicly visible?) I assume no.
3) What happens, if I want to update one bundle which is part of a deployed par file?
3.1) Will I have to re-deploy (and thus re-package) the full par file (including all modules) again?
3.2) If I don't have to re-deploy the par, how can I decide - having two times the same par or even various par's all using the same bundle - for which par I update the bundle? Is this some kind of "all or nothing" update (meaning: If I can't decide, will all pars referring to that bundle and assuming their Import-Bundle:version string permits it automatically start using it?)
4) What happens to a pure OSGi bundle in an environment where the same bundle is contained in pars already? Will it just "never be used"? I assume yes (never used)

Correct me if I'm wrong, but currently I think 3.1 is the case. Which somehow is a pitty, because one of the reasons I'd like to start using OSGi is, because everything is modular and I can "quickly deploy fixes for modules" independently of each other. Forcing me to build the full par again is tricky in an automatted build environment (usual setups would probably re-compile all modules and thus produce a par where not only the failing module is updated, but all other modules as well - which is not necessarily what I want).

Concerning 4) I think this can be quite error prone for the "poor deployer". He thinks he updated bundles in pars, but in fact he did not, instead the bundle "is just there" doing nothing.

Somehow I wish, the par concept would be supported on a lower level - that is: Directly in the OSGi spec. That may partly be the case already (with your extensions to equinox). However, I'd prefer, if the whole spec supported "group scopes", where I could
- deploy modules / updates "into an existing group scope"
- getting the status about grouped bundles directly in the OSGi console
- start / stop the whole group on OSGi console level
etc.

I hope, I'm not completely off-track here, but I'm sure you gonna tell me, if I am ;-)

Thanks for any thoughts and answers.
Regards
Kay

[robh]

Kay,

1) You can deploy the same PAR file provided you give it a different version.

2) Pure OSGi bundles cannot have dependencies into PAR-packaged bundles as you guessed. This is to enforce the scoping provided by the PAR.

3.1) You can update just one bundle in a PAR using the JMX-exposed deployer API. For now this API is considered to be internal but it is exposed via the tooling and JMX. So when a bundle in a PAR project is refreshed in the tools, only that bundle is updated not the whole PAR file.

3.2) If a bundle is packaged inside a PAR, then no other PAR can refer to it. So if you were to package PAR com.mypar at version 1 and version 2, each PAR would have its own distinct set of bundles. So, when you come to refresh a bundle in a PAR you can choose which version of the PAR you would like to trigger the refresh in. Essentially the command becomes something like: refresh bundle 'foo' in PAR from URI 'file:///home/robh/foo.par'.

If a bundle is packaged outside a PAR and then referenced by both PARs, then refreshing that global bundle will affect what both PARs see.

4) If the same bundle exists both inside a PAR and globally, then the bundles inside the PAR will see the PAR version. However, global bundles will see only the non-PAR version.

I would, where possible, avoid packaging any globally visible bundles inside a PAR. If something is truly a globally shared library then it should be packaged as such. If you do have this situation, the deployer can query the bundle wiring metadata in the console to be certain of the bundle she should update. Our deployer API handles this and in the next version of the Platform we will support this as a public API.

We too hope to have groups/scopes as part of the OSGi spec and it was a requirement that has been raised a few times now in the Expert Group and has certainly been a topic of some discussion.

Regards,

Rob

[Beta User]

Thanks a lot for these insights Rob - very appreciated.

Looking forward to some "convenient" "refresh bundle in PAR ..." functionality ;-)

Regards,
Kay

[Beta User]

After some discussions with my co-workers I have some follow up question to the par concept:
1) When multiple pars include the same bundle with the same version, is the bundle gonna be running once or multiple times (e.g. once per par)? I assume it's not shared between pars - which is, compared to raw OSGi, a step back. It would be great, if same bundles really run only once, and that this is assured "under the hood" by some equinox extension - with the consequence that deploying an update to such a shared bundle of a particular par would mean to not share it any longer and introduce an explicitely different bundle for the respective par (whereas all other pars continue to use the previous shared bundle).

2) I don't think you need to expose the deployment API (yet), but you may want to improve the functionality for deployment in your admin console (as currently, it is rather very reduced to the minimum...). I created https://issuetracker.springsource.com/browse/PLATFORM-128 as I'm sure, implementing "in-par bundle update" (and some more, related tasks) would actually solve many problems of the par concept from the beginning.

What do you think?

Regards
Kay

[Beta User]

you guys where thinking about cross-par visibility.
Is this still in scope or simply removed ??

[Glyn Normington]

Cross-PAR visibility including sharing of bundles contained in PARs (with or without a "copy on write" feature as suggested by Kay) is not in scope for v1.0 and we are very unlikely to add it in the future as it breaks the PAR concept. Bundles that need to be shared between PARs must be broken out as stand-alone bundles (or libraries if appropriate).

PLATFORM-128 is a reasonable requirement, and thanks for logging it.

[vishalj]

I am facing a similar problem but dont know how to use this deployer API ,am not clear with the methods arguments in Deployer

My problem is i want to update a bundle within a PAR

[Sam Brannen]

I am facing a similar problem but dont know how to use this deployer API ,am not clear with the methods arguments in Deployer

My problem is i want to update a bundle within a PAR

FYI: for others following this thread, I've provided information regarding the Deployer API here: http://forum.springframework.org/showthread.php?p=217804#post217804

Regards,

Sam