RE: [equinox-dev] server side OSGi platform, developing a launch configu

["Kaegi, Simon" <Simon.Kaegi@xxxxxxxxxx>]

Hi Jochen, 

> To enhance the development process, I just started developing 
> a plugin to launch a server side OSGi application within a 
> web container.
Neat idea. I'd never really considered a launcher for the servlet
bridge.
For development, I do the vast majority of my work by launching an
equinox application that contains an internal HttpService (e.g.
org.eclipse.equinox.http).
I use the servlet bridge as well but generally only in the final stages
of testing a deployment.

> Basic idea is:
> - Define a new launch configuration, incl. all the properties 
> from OSGi Equinox launcher
> - Add a tab to this launcher, add properties for
> 	- The target (e.g. Tomcat, Jetty)
> 	- the target directory
> 	- a reference to a bridge project (e.g. 
> org.eclipse.equinox.servlet.bridge)
> (or use a default one)
> 	- a context name, where the bride will be deployed 
> (e.g. defaults to
> "bridge")
Comment: This tab sounds a little like the WTP deploy tool

> 
> The configuration (config.ini) will be stored within PDE, the 
> plugins be taken from workspace (reference:file:...), the 
> workspace can be somewhere.
> 
> 
> This requires some changes of FrameworkLauncher:
> 
> 1. During startup, give a chance to set
> 	- osgi.install.area
> 	- osgi.configuration.area
> 	- osgi.instance.area
> to appropriate values.
> 
> 2. I enabled the bridge servlet to process commandline args 
> when starting the framework launcher. Commandline args can be 
> specified in web.xml as init parameter. (e.g. -configuration 
> path, -data path, and -install path)
> 
> 3. Default lookup should be as in current implementation: 
> search at /WEB-INF/platform, copy platform to temp dir
> 
> 4. If we specify the osgi.install.area, we do NOT copy the 
> resources to container temp
> 
> 5. If we specify the osgi.configuration.area, we do NOT copy 
> the resources to container temp
> 
> 6. If we specify the osgi.instance.area, we do NOT copy the 
> resources to container temp
> 
> 
> 
> Some questions remains open for me:
> 
> 1. Why do we have an explicit step to deploy/undeploy ? It 
> could be done as part of start/stop. No specific deployment 
> needed when running from files.
Deploy/undeploy provides controls to reset the platform.
(I find this very useful when testing remote deployment mechanisms.)
Also deploy/undeploy provide reasonable places to extend the
FrameworkLauncher.

> 2. What does osgi.configuration.cascaded=false in config.ini 
> mean ? (sorry if it is a stupid question)
If set "true" it's used in shared configuration situations. 
I was concerned about this at one point but maybe this can be removed.

> 3. It would be a 
> good idea, to parse the config.ini before startup, to get all 
> properties which are relevant for EclipseStarter.run():
> 	- e.g. osgi.framework, osgi.noShutdown, ...
I agree this might be a good idea -- the processing of settings from
config.ini also won't overwrite existing properties which in some
situations is a real problem.

> 4. As mentionend in code from Simon Kaegi, some code portions 
> from EclipseStarter should be made visible. Same would apply 
> to processCommandlineArgs too
Hmm... I'm fine with state of EclipseStarter in M5. The code I was
referring to was to do with duplication of some stuff from boot.jar.
Rather than processCommandlines you might look at setInitialProperties
instead.

 5. What would be the preferrred 
> package for the server side OSGi launcher ?
> Same place as EquinoxLaunchConfiguration, in 
> org.eclipse.pde.ui.launcher ?
Separate plugin probably.

> I have a running implementation of FrameworkLauncher, which I 
> can submit to Equinox. Should I open an enhancement request 
> for an launcher to startup server side OSGi, and attach the 
> patch of FrameworkLauncher ?
Is it possible to do this by extending the FrameworkLauncher instead?
It might require some changes for configuration but some of the changes
you need are probably going to happen anyway. Another thought for the
debug.core extension launcherCT side, I don't know what's involved in
creating the "debug" side of this. Anyway, if there was a launcher
available today for this stuff then I'd use it;) Open a request and we
can continue talking about it.

-Simon
 
     This message may contain privileged and/or confidential information.  If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so.  Thank you.