|
| Re: calling an activator class from a contributor plugin [message #93121 is a reply to message #93091] |
Thu, 26 July 2007 17:57   |
Eclipse User |
|
|
|
Originally posted by: jacek.pospychala.pl.ibm.com
Anoton,
it's by design, that bundle doesn't start as long as it's not needed. If
you wish to start it immediately after equinox launch, you may add it to
osgi.bundles in configuration/config.ini
Anton Arhipov wrote:
> Hello!
>
> I have following case: two bundles - a core and a contributor. The
> core bundle consists of several classes that are used in the
> contributor's manifest and the contributor doesn't contain any classes
> at all.
>
> For the contributor I want to use a class from the core bundle, that
> extends AbstractUIPlugin class. This class is *not* the activator for
> the "core" plug-in, as far as core is concerned, this is just another
> class. In the "contributor" plug-ins, I specify this class as the
> activator (the contributor has "core" plug-in as a dependency).
>
> The problem is that a start(BundleContext context) of that activator
> class is not being called. As I mentioned already the contributor
> bundle doesn't contain any classes itself, so no classes being loaded,
> and the activator doesn't get loaded. Is there a way to overcome this
> issue and make the activator to start, or this might be a bug ?
>
> Anton
|
|
|
| Re: calling an activator class from a contributor plugin [message #93134 is a reply to message #93121] |
Thu, 26 July 2007 18:25 |
 Anton Arhipov
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
Jacek Pospychala wrote:
> Anoton,
> it's by design, that bundle doesn't start as long as it's not needed. If
> you wish to start it immediately after equinox launch, you may add it to
> osgi.bundles in configuration/config.ini
Thx Jacek. This could be an option. However, the contributor should have
been activated since I have an actionSet defined in the plugin.xml for
the contributor bundle:
say, foo.bar.Action extends IobjectActionDelegate is in core bundle. And
in contributor i use it for actionSet declaration. the same way I have a
foo.bar.Activator that implements BundleActivator (in core) which is
used by the contributor, like Bundle-Activator: foo.bar.Activator
>
> Anton Arhipov wrote:
>> Hello!
>>
>> I have following case: two bundles - a core and a contributor. The
>> core bundle consists of several classes that are used in the
>> contributor's manifest and the contributor doesn't contain any classes
>> at all.
>>
>> For the contributor I want to use a class from the core bundle, that
>> extends AbstractUIPlugin class. This class is *not* the activator for
>> the "core" plug-in, as far as core is concerned, this is just another
>> class. In the "contributor" plug-ins, I specify this class as the
>> activator (the contributor has "core" plug-in as a dependency).
>>
>> The problem is that a start(BundleContext context) of that activator
>> class is not being called. As I mentioned already the contributor
>> bundle doesn't contain any classes itself, so no classes being loaded,
>> and the activator doesn't get loaded. Is there a way to overcome this
>> issue and make the activator to start, or this might be a bug ?
>>
>> Anton
|
|
|
| Re: calling an activator class from a contributor plugin [message #93375 is a reply to message #93134] |
Tue, 31 July 2007 17:24 |
|
Anton Arhipov wrote:
>
> Thx Jacek. This could be an option. However, the contributor should have
> been activated since I have an actionSet defined in the plugin.xml for
> the contributor bundle:
>
> say, foo.bar.Action extends IobjectActionDelegate is in core bundle. And
> in contributor i use it for actionSet declaration. the same way I have a
> foo.bar.Activator that implements BundleActivator (in core) which is
> used by the contributor, like Bundle-Activator: foo.bar.Activator
Except AFAIK lazy instantiation applies to class loading. When eclipse
tries to instantiate your actionSet it'll load foo.bar.Action and that
will trigger/make sure the core bundle is active. It doesn't care that
the actionSet definition came from the contributor bundle.
I don't believe there is any intrinsic eclipse mechanism to start a
bundle with no classes to load, unless you track it down and do it
manually or (as previously mentioned) include it in the osgi.bundles
property. But in either case, you have to be careful that any framework
the contributor needs is available when its bundle starts.
Later,
PW
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions
|
|
|
|
|
|
|
|
|
|
|
| Re: calling an activator class from a contributor plugin [message #93951 is a reply to message #93775] |
Thu, 02 August 2007 17:47 |
| Eclipse User |
|
|
|
Originally posted by: alex_blewitt.yahoo.com
That's the same behaviour for Java code, though. Doesn't really matter whether it's compiled or not.
You still get a hit when something starts up; Eclipse delays that as long as possible. What kind of initialization are you trying to do?
Alex.
|
|
|
|
| Re: calling an activator class from a contributor plugin [message #93995 is a reply to message #93966] |
Thu, 02 August 2007 22:52 |
| Eclipse User |
|
|
|
Originally posted by: alex_blewitt.yahoo.com
Yeah, but the view is only activated when it's shown. For the server case, it's run via a separate Java process with an -application; and that's consulted from the extension registry to start the bundle that contains that extension point. The startup is triggered by the update.configurator and the core runtime, and they're started by entries in the osgi.bundles property of the configuration.ini
The point is that the default behaviour for bundles is for them not to be started unless absolutely necessary. If you want to do something else then you've got to explicitly start it via the osgi.bundles, or implement a command line application which will cause that bundle to be started.
However, which one is right for you very much depends on what you want the bundle to do -- if you don't know the answer to that question, then you can't really solve the problem you're trying to.
Alex.
|
|
|
|
| Re: calling an activator class from a contributor plugin [message #94067 is a reply to message #94053] |
Fri, 03 August 2007 11:26 |
| Eclipse User |
|
|
|
Originally posted by: alex_blewitt.yahoo.com
I am unable to help you further. You wish for something to be running before something is running to be able to run it, and I can't seem to convince you that something needs to be running before something can run the thing that you want to run; yet, you insist that you want to be able to run things that aren't running by something that's also not running.
Good luck, and I hope you find your way out of your paradox.
Alex.
|
|
|
|
|
|
|
| Re: calling an activator class from a contributor plugin [message #94341 is a reply to message #94335] |
Tue, 07 August 2007 09:10 |
Anton Arhipov
Messages: 15
Registered: July 2009 |
Junior Member |
|
|
> It is more safe to get the contributing bundle with the following code
> in an OSGi environment.
> if (contributor instanceof RegistryContributor) {
> BundleContext context = getBundleContext();
> try {
> long id =
> Long.parseLong(((RegistryContributor) contributor).getActualId());
> return context.getBundle(id);
> } catch (NumberFormatException e) {
> // try using the name of the contributor below
> }
> }
> Currently the extension registry only understands singleton bundles so
> the contributor name is always going to be unique within a framework.
> But we would like to loosen this restriction in the future. With the
> code above you can use the RegistryContributor SPI to get the real
> bundle ID of the contributor.
Tried that, nice, thanks for the notice!
> In you call to Bundle.findEntries, why do you pass true to recurse into
> subdirectories? Doesn't this prevent the same file name to exist in
> different directories?
I did not think about it, to be honest. I should use 'false' indeed.
> If the bundle is not going to have any java code at all then how are you
> going to implement a BundleActivator in groovy? When a bundle is
> activated its BundleActivator is called. But the framework currently
> only understands how to load a bundle activator if it is a java Class
> that implements BundleActivator. We can work to figure out how to
> activate a bundle that you load a script from, but I don't think it is
> going to be very interesting to activate a bundle that has no
> BundleActivator class.
I'm going to provide a facade BundleActivator in which run() method I will
delegate the call to a activator.groovy run() function.
For now I will just presume that a user will have to create an activator.*
script to be able to use the activator. I agree it is not the best
solution but at the moment it is just a proof of the concept. So far I
have only the proxy for extension, and the activator facade that will be
required for using the plugin to write bundles using the scripting
languages.
> I'm a groovy novice, but I played with both scala and groovy to write
> OSGi bundles. In both of these cases I used some Eclipse tools that
> compiled the script files into real java classes. Lets call this the
> pre-compiled approach. Basically I had a library bundle that exported a
> bunch of packages that the precompiled groovy code depended on. Then
> the groovy bundle would require the groovy library bundle. To the OSGi
> Framework the code all looks like normal javacode so everything works
> well in that environment.
This is something that James Ervin described here. Compiling the scripts
into class files and just referring to them in the plugin.xml.
http://iacobus.blogspot.com/2007/03/add-groovy-to-your-eclip se-plugin.html
I didn't want to precompile anything as I wanted to make it more "generic"
in sense of non-compilable scripts. That is why I just evaluate the
scripts and not compile them to bytecode.
> It may be interesting is to see if the same approach can be done but
> instead compile the scripts into java bytecode at runtime. There are
> some hooks in Equinox that allow you to hook into the classloader. Have
> you considered trying to plugin to the classloader to compile and load
> groovy bytecode on the fly? If you could do that then the plugin.xml
> could just reference the classname of the compiled groovy code, not sure
> if that is a reliable class name or not.
This is interesting. I think I will investigate it more a bit later.
But the pitfall is that you couldn't rely on the style in which the
scripts is written, e.g the script might not have any classes defined - it
might containt only functions and then the class name would have name like
"Script1" or something... even if the script name is action.groovy
So you cannot be sure about the name of the compiled class.
> That approach could work for groovy and scala where the language can be
> compiled into bytecode, but last I checked JRuby does not have an option
> to compile ruby scripts to java bytecode.
There isn't a separate jruby->bytecode compiler, but actually the bytecode
is being run in the JVM so it is being generated at the runtime when one
runs "jruby filename". AFAIK jruby uses ASM to generate the bytecode on
the fly.
|
|
|
|
Powered by
FUDForum. Page generated in 0.04489 seconds
] 
Search
Help
Register
Login
Home
