So what is the core deployment scenario for dev / qa / prod

So if I have a webapp for an admin UI for a Spring MDP service. Spring MDB service in turn wires 7 other services (Spring beans) to process messages. I like the "hints" in the docs that each of these components can be deployed and managed independently - esp. as these service components are 100% stateless.

1) What is Best Practice(BP) for deploying - Par? Use Repo for all services bundled & deployed independently?

2) Assuming I want this automated (like by Maven scripting), I would just copy all of the above to the repo dirs? And then what is BP for property files? Eg. each one of those services needs 1 or more property files for each of dev/stage/prod? There are several known paths for handling property files for different envs in WebSphere (our current), what is the S2App Best Practice way?

3) When upgrading a service , I like that OSGI permits upgrades without a restart. How does war upgrading work - eg. deploy version 1.0 originally, i just copy it in to pickup / repo. Now I have 1.01 or 2.0 - how do I deploy (uninstall other services before or after); and after it has started, start forwarding all http requests with the given web context to the new server?

To get tricky - do the same thing (upgrade service version) for Spring Mdps, listening on a given Q ; let requests in progress complete, then the "deactiveate" (stop JMS Listener) ; with all new requests going to 1.0.1

1) Using a PAR is the best practice if you are deploying an application made of closely related bundles. If your bundles are effectively separate, then using individual bundles is fine, but you'll want to use the Admin Console for deploying rather than hot deploy to guarantee startup ordering.

2) The way I would achieve this is to use the OSGi Config Admin service. Spring-DM provides property placeholder support for pulling values from CA - the only challenge is getting them in there. It should be pretty easy for you to create a bundle that adds property file values into CA. We plan to support this directly in a future version of the Platform.

3) We have no support for doing this kind of upgrade automatically yet, so you are unlikely to be able to get seamless failover. We will be supporting this, just not in version 1.0.

Regards,

Rob

Hi Rob,

I've been looking into trying what you talk about in #2, populate the Configuration Admin. However, unless i'm missing something, the current beta6 of S2AP does not come with a Configuration Admin, nor does it seem to come with the OSGi Compendium Services library bundle. I can add these, but it seems to me that it would make sense for the application platform to include a configuration admin at least, is this intentional or is this going to be resolved before 1.0.0 is final? If i'm missing something (which may very well be the case) please let me know.

We have intentionally left CA out of the Platform because we are not using it as yet. You can get the Equinox CA bundle from the Equinox downloads at: http://download.eclipse.org/eclipse/equinox/drops/S-3.4RC4-200806091311/index.php. You need the org.eclipse.equinox.cm_1.0.0.v20080509-1800.jar and org.eclipse.osgi.services_3.1.200.v20071203.jar bundles.

We will be including explicit CA support in the next release.

Rob

Thanks for your response Rob, yes i did get Equinox cm after posting my comment. I just felt it was something important missing from S2AP, specifically because it is a great feature included in Spring-DM and something i hope more people take advantage of. Hopefully S2AP can provide bundles for features that it might not directly use, but for which including would help set it as a great OSGi platform in general.

It's a pretty difficult balancing act for us. There are *so* many bundles we want to include, but we try to restrict ourselves to the bundles that are absolutely necessary. If enough people want CA support in the short term we'll consider adding it, but it will definitely be part of the next release.

Rob

Oh, by "next release" do you mean beta7 or 2.0? Although it is completely possible for me to work around it as i have done. It seems to me that this is a great candidate to include, most specifically because Spring-DM has direct support for it, and it really gets to something that is going to be key to a lot of applications, you know, configuration :)

In fact, i was a bit disappointed to find out that S2AP doesn't use ConfigurationAdmin itself for configuration, i was hoping i would be able to administrate it via some of my existing tooling. I read that in 2.0 you guys are going to work on clustering and configuration, so hopefully you do intend at that point to make the jump to ConfigurationAdmin for your internal configuration as well.

By next release I mean 2.0.

We aren't totally sure about CA for our internal config yet - we have some pretty complex trees of config, and a simple Dictionary approach is not ideal. If we can find some elegant way of mapping these trees to the Dictionary we may choose to add a CA front on to our config.

Rob

Picking up this very interesting topic: I just want to make sure that you know, there are more people out there waiting for CA to be integrated into S2AP (I officially support kabriel's view on this :-) )

IMO it is essential, to have a possibility to configure your bundles specific to the platform it runs on. I cannot think of many cases where you'd want to deploy preconfigured bundles - and you don't want to change the configuration over time.
Having said that, I think it would greatly improve the "access" to and usability of the S2AP platform, if you'd not only include CA as an "infrastructure service" which is just there, but also promote it in your documentation (probably even beyond the Spring DM - where it "only" has some short appendix about it), provide an example and for sysadmins easy config access in your admin console.
Imagine how easy life would be to have configuration access as a link in the admin console directly where the bundles of my deployed application are listed. Click on it and see all relevant configuration options. Modifying them directly in the console would be even greater - and although that requires some effort on the bundle provider: Updating the already running beans if intended by the developer would just be awesome (according to the ModuleService and ModuleServiceFactory idea).

I don't know what other bundles you see to be of similar importance, but I vote for giving CA a special head start advantage and include it as soon as possible...

I'm looking forward to comments from other Beta users on this topic!
Regards
Kay

CA is indeed essential for production releases of S2AP (certainly in my job).

S2AP is great and the reason for that is it is a different model to a monolithic web app running on a monolithic app server, but you do 100% need a web based admin gui for configuring bundles.

As I've mentioned on another thread an important admin function would be the configuration of bundles to point at other bundles deployed as data sources, without support like this I can't possibly recommend S2AP in a production environment as the sys admins would have none of it.

It's a must have - without it S2AP would be a very elegant, but academic piece of software, and no one wants that.