| standalone osgi [message #41957] |
Thu, 06 May 2004 09:13  |
Eclipse User |
|
|
|
Originally posted by: egglersim.post.ch
aiming to create a service framwork that runs inside eclipse as well as
anywhere else (specifically inside a webapp), i'm trying to run the
eclipse osgi runtime without eclipse.
i wish to replace the eclipseAdaptor with a custom implementation that
writes configuration and other meta-data not to a file based repository
but rather to a database.
i have looked into avalon/fortress as my service framwork, but since
having avalon AND osgi inside eclipse doesn't make much sense (imo), i
have decided to stick to osgi only.
does anyone have experience using osgi within webapplications or using the
eclipse osgi implementation standalone?
i need some advice here, does using osgi within a webapplication make
sense or should i rather use avalon/fortress and osgi side by side?
cheers,
simon
|
|
|
| Re: standalone osgi [message #41988 is a reply to message #41957] |
Thu, 06 May 2004 10:06  |
| Eclipse User |
|
|
|
Originally posted by: thoean.yahoo.de
I hope I understood your problem fully:
> does anyone have experience using osgi within webapplications or using the
> eclipse osgi implementation standalone?
I am currently creating the following solution (command line
application, without the org.eclipse.ui.* stuff):
- one plugin extends org.eclipse.core.runtime.IPlatformRunnable. It
includes support for org.ec..tomcat and org.ec...help.appserver.
- other plugins use org.eclipse.help.internal.appserver.WebappManager to
start and stop webapplications. They can use this by being dependent on
my main application plugin.
Markus
|
|
|
| Re: standalone osgi [message #42047 is a reply to message #41988] |
Thu, 06 May 2004 15:48 |
| Eclipse User |
|
|
|
Originally posted by: egglersim.post.ch
Markus Thurner wrote:
> I hope I understood your problem fully:
> > does anyone have experience using osgi within webapplications or using the
> > eclipse osgi implementation standalone?
> I am currently creating the following solution (command line
> application, without the org.eclipse.ui.* stuff):
> - one plugin extends org.eclipse.core.runtime.IPlatformRunnable. It
> includes support for org.ec..tomcat and org.ec...help.appserver.
> - other plugins use org.eclipse.help.internal.appserver.WebappManager to
> start and stop webapplications. They can use this by being dependent on
> my main application plugin.
> Markus
i'd like to get rid of the eclipse stuff altogether.... in other words:
the only dependendcy i'd like to have is on the jars that are located
inside the osgi bundle. the bundles i provide are standard osgi bundles
that derive from the osgi BundleActivator class.
simon
|
|
|
|
| Re: standalone osgi [message #42108 is a reply to message #42047] |
Fri, 07 May 2004 00:44 |
| Eclipse User |
|
|
|
Originally posted by: pascal.ibm.canada
The implementation available contains 2 adaptors:
the eclipse adaptor, and the default adaptor.
The eclipse adaptor contains all the eclipse spscific stuffs, whereas
the other is a pure osgi implementation (it still contains the
enhancements that have been done like provide / requires. However if you
don't use those headers the implementation is osgi 3.0 compliant - we
internally run the TCK). The eclipseAdaptor inherits from the
defaultAdaptor and we pay attention to keep the separation clear.
To run the default adaptor you can use the 2 application launchers (see
menu run / debug) that are automatically added to your launcher list
when you get the code from the repository.
Given what you want to do, the best thing for you is to create your own
adaptor that inherits from the default one. The concept of adaptor has
been specifically designed to do what you are trying to do, and doing
the modification you want should be straightforward.
If you have other questions post here and will be api to help.
PaScaL
Simon Eggler wrote:
> Markus Thurner wrote:
>
>
>>I hope I understood your problem fully:
>
>
>>>does anyone have experience using osgi within webapplications or using the
>>>eclipse osgi implementation standalone?
>
>
>>I am currently creating the following solution (command line
>>application, without the org.eclipse.ui.* stuff):
>
>
>>- one plugin extends org.eclipse.core.runtime.IPlatformRunnable. It
>>includes support for org.ec..tomcat and org.ec...help.appserver.
>>- other plugins use org.eclipse.help.internal.appserver.WebappManager to
>>start and stop webapplications. They can use this by being dependent on
>>my main application plugin.
>
>
>
>>Markus
>
>
> i'd like to get rid of the eclipse stuff altogether.... in other words:
> the only dependendcy i'd like to have is on the jars that are located
> inside the osgi bundle. the bundles i provide are standard osgi bundles
> that derive from the osgi BundleActivator class.
>
> simon
>
>
|
|
|
| Re: standalone osgi [message #42196 is a reply to message #42108] |
Mon, 10 May 2004 07:36 |
| Eclipse User |
|
|
|
Originally posted by: egglersim.post.ch
i have tried running the default adaptor, but when launching the eclipse
osgi bundle (wich i obviously need) i get the folowing exceptions:
see:
http://www.eclipse.org/newsportal/article.php?id=879&gro up=eclipse.technology.equinox
i also have another question:
when creating a bundle as osgi-compliant bundle (within eclipse), the
plugin is not instantiated on use. how do i get eclipse to create the
plugin (subclass of org.eclipse.core.runtime.Plugin) and call the start
method?
here's the example code (adapted from oscar tutorial):
#MANIFEST.MF
Manifest-Version: 1.0
Bundle-Activator: dictionaryenglish.DictionaryEnglishPlugin
Bundle-Localization: plugin
Bundle-SymbolicName: ch.post.pf.gui.sfw.prototype.dictionary.en
Bundle-Vendor: betelgeuse.org
Bundle-Name: English dictionary
Bundle-Description: A bundle that registers an English dictionary service
Bundle-ClassPath: dictionary-english.jar
Bundle-Version: 1.0.0
Require-Bundle: org.eclipse.core.runtime
Export-Package: dictionary.spi
<!-- plugin.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin
id="ch.post.pf.gui.sfw.prototype.dictionary.en"
name="Dictionaryenglish Plug-in"
version="1.0.0"
provider-name="betelgeuse.org"
class="dictionaryenglish.DictionaryEnglishPlugin">
<runtime>
<library name="dictionary-english.jar">
<export name="dictionary.spi"/>
</library>
</runtime>
<requires>
<import plugin="org.eclipse.core.runtime"/>
</requires>
</plugin>
//DictionaryEnglishPlugin.java
package dictionaryenglish;
import org.eclipse.core.runtime.Plugin;
import org.osgi.framework.BundleContext;
import dictionary.spi.DictionaryService;
/**
* The main plugin class to be used in the desktop.
*/
public class DictionaryEnglishPlugin extends Plugin {
//The shared instance.
private static DictionaryEnglishPlugin plugin;
/**
* Implements BundleActivator.start(). Registers an
* instance of a dictionary service using the bundle context;
* attaches properties to the service that can be queried
* when performing a service look-up.
* @param context the framework context for the bundle.
**/
public void start(BundleContext context) throws Exception
{
super.start(context);
Properties props = new Properties();
props.put("Language", "English");
context.registerService(
DictionaryService.class.getName(), new DictionaryImpl(),
props);
}
/**
* Implements BundleActivator.stop(). Does nothing since
* the framework will automatically unregister any registered services.
* @param context the framework context for the bundle.
**/
public void stop(BundleContext context)
{
// NOTE: The service is automatically unregistered.
}
/**
* Returns the shared instance.
*/
public static DictionaryEnglishPlugin getDefault() {
return plugin;
}
}
Pascal Rapicault wrote:
> The implementation available contains 2 adaptors:
> the eclipse adaptor, and the default adaptor.
> The eclipse adaptor contains all the eclipse spscific stuffs, whereas
> the other is a pure osgi implementation (it still contains the
> enhancements that have been done like provide / requires. However if you
> don't use those headers the implementation is osgi 3.0 compliant - we
> internally run the TCK). The eclipseAdaptor inherits from the
> defaultAdaptor and we pay attention to keep the separation clear.
> To run the default adaptor you can use the 2 application launchers (see
> menu run / debug) that are automatically added to your launcher list
> when you get the code from the repository.
> Given what you want to do, the best thing for you is to create your own
> adaptor that inherits from the default one. The concept of adaptor has
> been specifically designed to do what you are trying to do, and doing
> the modification you want should be straightforward.
> If you have other questions post here and will be api to help.
> PaScaL
> Simon Eggler wrote:
> > Markus Thurner wrote:
> >
> >
> >>I hope I understood your problem fully:
> >
> >
> >>>does anyone have experience using osgi within webapplications or using the
> >>>eclipse osgi implementation standalone?
> >
> >
> >>I am currently creating the following solution (command line
> >>application, without the org.eclipse.ui.* stuff):
> >
> >
> >>- one plugin extends org.eclipse.core.runtime.IPlatformRunnable. It
> >>includes support for org.ec..tomcat and org.ec...help.appserver.
> >>- other plugins use org.eclipse.help.internal.appserver.WebappManager to
> >>start and stop webapplications. They can use this by being dependent on
> >>my main application plugin.
> >
> >
> >
> >>Markus
> >
> >
> > i'd like to get rid of the eclipse stuff altogether.... in other words:
> > the only dependendcy i'd like to have is on the jars that are located
> > inside the osgi bundle. the bundles i provide are standard osgi bundles
> > that derive from the osgi BundleActivator class.
> >
> > simon
> >
> >
|
|
|
|
| Re: standalone osgi [message #43847 is a reply to message #42258] |
Mon, 28 June 2004 19:22 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
If you want to run just OSGi then you can follow Pascal's suggestions and
use the Default Adaptor included in org.eclipse.osgi. Note that if you do
this, you cannot do anything related to Eclipse. That is, the Eclipse
Adaptor structures its data and exposes some services that are fundamental
to the operation of Eclipse itself. So the ideas that you would use
standard OSGi AND then want to get automatic activation of your bundle are
conflicting. The latter is not standard (or even common) OSGi behaviour.
It is purely Eclipse and is infact implemented in the Eclipse Adaptor.
(btw, if you have a manifest.mf and want autoactivation AND are using the
EclipseAdaptor then you can put
Eclipse-AutoStart: true
in the manifest to get your bundle started on first reference. Otherwise
you have ot use whatever technology you would use if using some other OSGi
implementation to get your bundle started.
Going forward there is some work to do to minimize the Eclipse Adaptor and
ween Eclipse itself off of various services or make them optional.
Jeff
"Mike Hiner" <mhiner@itmassociates.com> wrote in message
news:c7qjei$gpl$1@eclipse.org...
> I had/have the same problem. So far the only solution I have had success
> with was to create an Eclipse 3.0 plug-in without a manifest. Then I
> override the start and stop functions since in M8 Plugin implements
> BundleActivator. I am assuming the creation of the manifest is most
useful
> for dynamic loading and unloading of plug-ins but for the moment I am just
> waiting for some documentation before I start using an actual manifest.
>
> The bahavior is a little confusing from a "pure" OSGi perspective since
the
> framework is launching the view, which is not exported, but not the
> Activator specified in the manifest. Until documentation is out out
though,
> I am not even sure if this behavior is correct.
>
>
>
>
> "Simon Eggler" <egglersim@post.ch> wrote in message
> news:c7nbdf$ln9$1@eclipse.org...
> > i have tried running the default adaptor, but when launching the eclipse
> > osgi bundle (wich i obviously need) i get the folowing exceptions:
> >
> > see:
> >
>
http://www.eclipse.org/newsportal/article.php?id=879&gro up=eclipse.technology.equinox
> >
> > i also have another question:
> > when creating a bundle as osgi-compliant bundle (within eclipse), the
> > plugin is not instantiated on use. how do i get eclipse to create the
> > plugin (subclass of org.eclipse.core.runtime.Plugin) and call the start
> > method?
> >
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03978 seconds
] 
Search
Help
Register
Login
Home
