[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
WG: [equinox-dev] server side OSGi platform, developing a launch configuation, changes to FrameworkLauncher
- From: "Jochen Hiller" <jo.hiller@xxxxxxxxxxxxxx>
- Date: Sun, 26 Feb 2006 14:42:02 +0100
- Delivered-to: firstname.lastname@example.org
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:reply-to:from:to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-priority:x-msmail-priority:x-mailer:importance:x-mimeole; b=g2DIKTUgLft1f8t8WY+DFRMXy5XK11Sco6O9inUtD7OPDlATA0WGe8Zg3gVZJYu8GBUFXFQ/W5Z6B8fgPsgnQUAsNeQw9NkzPFCPDOEgyywI1g5cd4M0FnJHcs0h0/fLpFe1y3DTER0YC+ydZnm6LqQf3YUexhiO0xXtP1r+S+Q=
- Importance: Normal
Sorry, sent via wrong email account. jo.hiller@xxxxxxxxxxxxxx is the correct
Von: Johann S. Miller [mailto:johann.s.miller@xxxxxx]
Gesendet: Sonntag, 26. Februar 2006 14:39
An: Equinox development mailing list
Betreff: AW: [equinox-dev] server side OSGi platform,developing a launch
configuation, changes to FrameworkLauncher
> > 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
> For development, I do the vast majority of my work by launching an
> equinox application that contains an internal HttpService (e.g.
> 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
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
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
from FrameworkLauncher, with some refactoring for FrameworkLauncher, for
resuse of code.
I open an enhancement request, including a patch for a
test cases, additional comments in web.xml etc.