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

["Jochen Hiller" <jo.hiller@xxxxxxxxxxxxxx>]

Hi Simon,

> > 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.

We are migrating a J2EE application to an server side OSGi application, so
we have a coexisting platform for the moment.


>
> > 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

Thanks for the hint, was one of my ideas too.


> > 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.

I implemented this one now.


> > 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.

I am using both: cmdline for at minimum specifying "-configuration <path>",
to get access to config.ini.
Other options could be in config.ini, fine.

>
>  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 will implement it within a separate plugin, but using package
org.eclipse.pde.ui.launcher,
for simple migration later if appropriate.


> > 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.

Thanks for your preparation (frameworkLauncherClass). I refactored it as a
subclass
from FrameworkLauncher, with some refactoring for FrameworkLauncher, for
better
resuse of code.

I open an enhancement request, including a patch for a
ConfigurationFrameworkLauncher,
test cases, additional comments in web.xml etc.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=129472.


Jochen