Home » Eclipse Projects » Equinox » aspectj load-time weaving works for OSGi
|
| Re: aspectj load-time weaving works for OSGi [message #31831 is a reply to message #31757] |
Tue, 06 January 2004 19:00   |
Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
We will address the bug in the next couple weeks. Expect something for M7.
As for the dependency info, the State interface is the thing you want. It
is not official API but will likely end up as "experimental" API in 3.0.
You should look at the PlatformAdmin service and from there get the current
state and traverse the state to find everything you need. Let us know if
there is something you need that you cannot get through this mechanism.
Jeff
"Martin Lippert" <lippert@acm.org> wrote in message
news:bsutb7$nk0$1@eclipse.org...
> Hi,
>
> I succeeded to integrate the load-time weaving for AspectJ into the M6
> version of the OSGi-based runtime. Thanks for the help.
>
> There are a few points where I somehow struggled with the OSGi runtime.
> Any ideas how to improve these things are welcome.
>
> - I wrote my own adaptor to create special class loaders, to start an
> additional bundle at startup time and to register a special service.
> That is all fine except from the fact that there is currently no
> official way to hook my adaptor into the system (as well as to provide
> some additional packages to other bundles). Therefore I wrote a bug
> report: https://bugs.eclipse.org/bugs/show_bug.cgi?id=48695
>
> - I need to add dependencies between bundles at runtime (as a result of
> a woven class, for example). I didn't find a way to do this via the
> normal dependency handling inside the OSGi runtime. I finally enhanced
> my special class loader with a list of additional required bundles.
> These bundles are asked to load a class if the first attempt to load the
> class fails. New required bundles can be added at runtime.
> -> works for me and does not require any changes to the Eclipse code.
> -> but is somehow duplicated code for dependency handling.
>
> - The weaver of AspectJ needs a lot of type information to weave a class
> (the class itself and all required types within that class and all
> required types of these classes and so on). In my first implementation
> for Eclipse 2.1 I collected all required plugins (recursively) for a
> plugin, asked for the classpath URLs of the plugins and added them to
> the weaver. This is more complicated inside the new runtime. Now I am
> using the Bundle.getResource method to load the bytecode for a class if
> the weaver asks for it. This is a lot more elegant than the old
> implementation but has one problem: Bundle.getResource loads only
> resources that are found within the bundle itself or required (or
> imported) bundles. I need to find even resources of bundles that are
> required (or imported) by required bundles and so on. Therefore I need
> an elegant way to collect all required (or imported) bundles from a
> bundle recursively. (This part is not part of my special adaptor so I
> can use only official API stuff. I found similar code inside the
> StateImpl class which I could not adapt because of internal API usage.)
>
> Any ideas and comments are welcome. Thanks!!!
>
> Best regards,
> Martin
>
>
>
>
|
|
|
| Re: aspectj load-time weaving works for OSGi [message #32008 is a reply to message #31831] |
Wed, 07 January 2004 10:41 |
 Martin Lippert
Messages: 124
Registered: July 2009 |
Senior Member |
|
|
Hi,
> We will address the bug in the next couple weeks. Expect something for M7.
Perfect!!! Thanks a lot for that!
> As for the dependency info, the State interface is the thing you want. It
> is not official API but will likely end up as "experimental" API in 3.0.
> You should look at the PlatformAdmin service and from there get the current
> state and traverse the state to find everything you need. Let us know if
> there is something you need that you cannot get through this mechanism.
Okay, the State interface seems to be pretty fine for that. Thanks for
the hint.
Any idea or comment about this:
I need to add dependencies between bundles at runtime (as a result of
a woven class, for example). I didn't find a way to do this via the
normal dependency handling inside the OSGi runtime. I finally enhanced
my special class loader with a list of additional required bundles.
These bundles are asked to load a class if the first attempt to load the
class fails. New required bundles can be added at runtime.
-> works for me and does not require any changes to the Eclipse code.
-> but is somehow duplicated code for dependency handling.
Thanks again!
Best regards,
Martin
>
> Jeff
>
> "Martin Lippert" <lippert@acm.org> wrote in message
> news:bsutb7$nk0$1@eclipse.org...
>
>>Hi,
>>
>>I succeeded to integrate the load-time weaving for AspectJ into the M6
>>version of the OSGi-based runtime. Thanks for the help.
>>
>>There are a few points where I somehow struggled with the OSGi runtime.
>>Any ideas how to improve these things are welcome.
>>
>>- I wrote my own adaptor to create special class loaders, to start an
>>additional bundle at startup time and to register a special service.
>>That is all fine except from the fact that there is currently no
>>official way to hook my adaptor into the system (as well as to provide
>>some additional packages to other bundles). Therefore I wrote a bug
>>report: https://bugs.eclipse.org/bugs/show_bug.cgi?id=48695
>>
>>- I need to add dependencies between bundles at runtime (as a result of
>>a woven class, for example). I didn't find a way to do this via the
>>normal dependency handling inside the OSGi runtime. I finally enhanced
>>my special class loader with a list of additional required bundles.
>>These bundles are asked to load a class if the first attempt to load the
>>class fails. New required bundles can be added at runtime.
>>-> works for me and does not require any changes to the Eclipse code.
>>-> but is somehow duplicated code for dependency handling.
>>
>>- The weaver of AspectJ needs a lot of type information to weave a class
>>(the class itself and all required types within that class and all
>>required types of these classes and so on). In my first implementation
>>for Eclipse 2.1 I collected all required plugins (recursively) for a
>>plugin, asked for the classpath URLs of the plugins and added them to
>>the weaver. This is more complicated inside the new runtime. Now I am
>>using the Bundle.getResource method to load the bytecode for a class if
>>the weaver asks for it. This is a lot more elegant than the old
>>implementation but has one problem: Bundle.getResource loads only
>>resources that are found within the bundle itself or required (or
>>imported) bundles. I need to find even resources of bundles that are
>>required (or imported) by required bundles and so on. Therefore I need
>>an elegant way to collect all required (or imported) bundles from a
>>bundle recursively. (This part is not part of my special adaptor so I
>>can use only official API stuff. I found similar code inside the
>>StateImpl class which I could not adapt because of internal API usage.)
>>
>>Any ideas and comments are welcome. Thanks!!!
>>
>>Best regards,
>>Martin
>>
>>
>>
>>
>
>
>
|
|
|
| Re: aspectj load-time weaving works for OSGi [message #32256 is a reply to message #32008] |
Fri, 09 January 2004 21:57 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
for adding dependencies, can you install bundles to add the dependencies?
This allows them to be added ot the state and properly managed by the
runtime.
Jeff
"Martin Lippert" <lippert@acm.org> wrote in message
news:btgnnq$3c1$1@eclipse.org...
> Hi,
>
> > We will address the bug in the next couple weeks. Expect something for
M7.
>
> Perfect!!! Thanks a lot for that!
>
> > As for the dependency info, the State interface is the thing you want.
It
> > is not official API but will likely end up as "experimental" API in 3.0.
> > You should look at the PlatformAdmin service and from there get the
current
> > state and traverse the state to find everything you need. Let us know
if
> > there is something you need that you cannot get through this mechanism.
>
> Okay, the State interface seems to be pretty fine for that. Thanks for
> the hint.
>
> Any idea or comment about this:
>
> I need to add dependencies between bundles at runtime (as a result of
> a woven class, for example). I didn't find a way to do this via the
> normal dependency handling inside the OSGi runtime. I finally enhanced
> my special class loader with a list of additional required bundles.
> These bundles are asked to load a class if the first attempt to load the
> class fails. New required bundles can be added at runtime.
> -> works for me and does not require any changes to the Eclipse code.
> -> but is somehow duplicated code for dependency handling.
>
> Thanks again!
>
> Best regards,
> Martin
>
>
>
>
> >
> > Jeff
> >
> > "Martin Lippert" <lippert@acm.org> wrote in message
> > news:bsutb7$nk0$1@eclipse.org...
> >
> >>Hi,
> >>
> >>I succeeded to integrate the load-time weaving for AspectJ into the M6
> >>version of the OSGi-based runtime. Thanks for the help.
> >>
> >>There are a few points where I somehow struggled with the OSGi runtime.
> >>Any ideas how to improve these things are welcome.
> >>
> >>- I wrote my own adaptor to create special class loaders, to start an
> >>additional bundle at startup time and to register a special service.
> >>That is all fine except from the fact that there is currently no
> >>official way to hook my adaptor into the system (as well as to provide
> >>some additional packages to other bundles). Therefore I wrote a bug
> >>report: https://bugs.eclipse.org/bugs/show_bug.cgi?id=48695
> >>
> >>- I need to add dependencies between bundles at runtime (as a result of
> >>a woven class, for example). I didn't find a way to do this via the
> >>normal dependency handling inside the OSGi runtime. I finally enhanced
> >>my special class loader with a list of additional required bundles.
> >>These bundles are asked to load a class if the first attempt to load the
> >>class fails. New required bundles can be added at runtime.
> >>-> works for me and does not require any changes to the Eclipse code.
> >>-> but is somehow duplicated code for dependency handling.
> >>
> >>- The weaver of AspectJ needs a lot of type information to weave a class
> >>(the class itself and all required types within that class and all
> >>required types of these classes and so on). In my first implementation
> >>for Eclipse 2.1 I collected all required plugins (recursively) for a
> >>plugin, asked for the classpath URLs of the plugins and added them to
> >>the weaver. This is more complicated inside the new runtime. Now I am
> >>using the Bundle.getResource method to load the bytecode for a class if
> >>the weaver asks for it. This is a lot more elegant than the old
> >>implementation but has one problem: Bundle.getResource loads only
> >>resources that are found within the bundle itself or required (or
> >>imported) bundles. I need to find even resources of bundles that are
> >>required (or imported) by required bundles and so on. Therefore I need
> >>an elegant way to collect all required (or imported) bundles from a
> >>bundle recursively. (This part is not part of my special adaptor so I
> >>can use only official API stuff. I found similar code inside the
> >>StateImpl class which I could not adapt because of internal API usage.)
> >>
> >>Any ideas and comments are welcome. Thanks!!!
> >>
> >>Best regards,
> >>Martin
> >>
> >>
> >>
> >>
> >
> >
> >
>
|
|
| |
| Re: aspectj load-time weaving works for OSGi [message #32400 is a reply to message #32291] |
Sun, 11 January 2004 02:16 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.ca.ibm.com
I think I see where you are going. I was off with the install bundles
comment.
What I am really trying to get at is that whatever mechanism you use, you
should not just hack something in to the classloaders. You need to actually
express the new dependency in the state. I will demonstrate using your
example.
Assume that C has been loaded and so now bundle A has a dependency on bundle
Y. What happens if Y is uninstalled? The OSGi framework detects who is
affected by traversing the state and associated datastrucutres. If you
dependency is not in there, bundle A will likely be left inconsistent.
The notion of dynamically adding dependencies is not foreign to OSGi. The
Dynamic-ImportPackage mechanism accomplishes this. For example, if all
bundles in your system had
Dynamic-ImportPackage: *
in their manifest.mf and they bundles supplying aspects had
Export-Package: <packages containing aspects>
in theirs, you woudl be quite happy.
This feels like the best route for you to follow.
Jeff
"Martin Lippert" <lippert@acm.org> wrote in message
news:btor3o$2go$1@eclipse.org...
> Hi,
>
> > for adding dependencies, can you install bundles to add the
dependencies?
> > This allows them to be added ot the state and properly managed by the
> > runtime.
>
> I am not sure what you exactly mean. Do you think of uninstalling and
> reinstalling bundles?
>
> Let me give you an example of my problem: bundle A is loaded and
> installed. Now class C of bundle A is loaded. At class loading my weaver
> weaves this class with aspect X of bundle Y. As a result the type of
> aspect X is referenced inside class C. Therefore bundle A needs to
> import a package of bundle Y (or require the complete bundle).
>
> This happens during class loading time and might occur after the bundle
> A is installed because class C is not the first class of bundle A that
> is loaded. Bundle A might already be working for a long time - same for
> bundle Y.
>
> The problem might be that this issue seems to be completely against the
> idea of bundle dependencies within OSGi. With OSGi each bundle defines
> which other bundles (or packages) are needed at bundle install time. I
> would like to change this while the bundle is already working. Do you
> think that this is somehow possible?
>
> Thanks again,
> Martin
>
|
|
| |
| Re: aspectj load-time weaving works for OSGi [message #32679 is a reply to message #32609] |
Mon, 12 January 2004 02:10 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.ca.ibm.com
"Martin Lippert" <lippert@acm.org> wrote in message
news:btsd8o$9fb$1@eclipse.org...
> I see that the dynamic package import stuff is the right way. But I am
> not sure whether I fully understood the mechanism. Three open questions:
>
> - any plugin that could be affected by an aspect would need to specify
> "Dynamic-ImportPackage: *" in the manifest. But I would like to weave
> existing plugins, for example several JDT plugins, with some aspects
> without adapting the plugins to the weaving (by adding the "*" dynamic
> import).
>
> - I know from the weaving which aspect is woven into which class.
> Therefore I am able to define the newly added dependencies exactly.
first two quesitons with one answer... There is no real magic here. At a
certain point in the class look up sequence we look for dynamic imports. At
that point you could (for question 1) automagically assume there is a * and
lookup any class or (for question 2), keep a list of classes you need to
depend on and look them up there.
The real issue here is how to ensure that the framework still behaves in the
face of dynamic uninstall/update. There will be details. I don't have the
code in front of me right now so cannot go further but suggest that making
your new classes look as much like dynamic imports as possible will be the
easiest path for you.
> - What does the "*" dynamic import means to the dynamic features of the
> runtime? What happens if a plugin specifies a "*" dynamic import and
> another plugin that exports some package is uninstalled?
This is handled correctly. The when something is uninstalled/updated the
framework effectively knows who has loaded classes from it and so who needs
to be kicked. The dependencies are reresolved and dependent bundles either
link up to a different bundle or become unresolved. It is here you want to
ensure that the dependencies you have dynamically added need to be handled.
> Is it somehow possible to tell the runtime to add some exact dynamic
> imports to installed bundles?
See above.
Jeff
|
|
| | |
| Re: aspectj load-time weaving works for OSGi [message #34356 is a reply to message #34218] |
Thu, 22 January 2004 02:32 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
"Martin Lippert" <lippert@acm.org> wrote in message
news:buk5r6$oip$1@eclipse.org...
> Hi,
>
> >> first two quesitons with one answer... There is no real magic here.
> >> At a
> >> certain point in the class look up sequence we look for dynamic
> >> imports. At
> >> that point you could (for question 1) automagically assume there is a
> >> * and
> >> lookup any class or (for question 2), keep a list of classes you need
to
> >> depend on and look them up there.
> >>
> >> The real issue here is how to ensure that the framework still behaves
> >> in the
> >> face of dynamic uninstall/update. There will be details. I don't
> >> have the
> >> code in front of me right now so cannot go further but suggest that
> >> making
> >> your new classes look as much like dynamic imports as possible will be
> >> the
> >> easiest path for you.
> >
> >
> > I took a look at the dynamic package import functionality and it seems
> > to me that mainly the BundleLoader deals with it. Therefore I don't know
> > how to add, for example, a new dynamic import to that loader or to
> > change the setting to "*" at runtime. Did I ignore something?
>
> Any idea on that?
Not right now. I'd have to dig through the code to see what is happening
where. what you say about the BundleLoader sounds right though. Try adding
something to bundle loader like addDynamicImport(). The implementation
should be reasonably straightforward. If you can prototype this we can look
at adding the support for real. Otherwise we are all up to our necks
preparing for EclipseCon and M7 so cannot be too proactive on non-critical
items.
Jeff
|
|
| |
| Re: aspectj load-time weaving works for OSGi [message #34558 is a reply to message #34490] |
Wed, 28 January 2004 15:25 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
Can you do what you need to or do you need changes? For now we can hack to
get you going and understand how to do this more elegantly later.
Jeff
"Martin Lippert" <lippert@acm.org> wrote in message
news:bus9dd$8d5$1@eclipse.org...
> Hi,
>
> >>>I took a look at the dynamic package import functionality and it seems
> >>>to me that mainly the BundleLoader deals with it. Therefore I don't
know
> >>>how to add, for example, a new dynamic import to that loader or to
> >>>change the setting to "*" at runtime. Did I ignore something?
> >>
> >>Any idea on that?
> >
> > Not right now. I'd have to dig through the code to see what is
happening
> > where. what you say about the BundleLoader sounds right though. Try
adding
> > something to bundle loader like addDynamicImport(). The implementation
> > should be reasonably straightforward. If you can prototype this we can
look
> > at adding the support for real. Otherwise we are all up to our necks
> > preparing for EclipseCon and M7 so cannot be too proactive on
non-critical
> > items.
>
> The BundleLoader has a method called "initDynamicImportPackage". This
> method could be used to add dynamic imports at runtime, from my point of
> view. For that it only has to be set to public visibility.
>
> The way to access this method (for example from my special adaptor or
> class loader) would still be somewhat ugly, but that might be okay (two
> ways to access the BundleLoader: cast from Bundle to BundleHost to call
> the method getBundleLoader on BundleHost or access the protected field
> of BundleClassLoader "delegate" to BundleLoader).
>
> Does that sounds reasonable?
>
> Thanks again!
>
> Best regards,
> Martin
>
|
|
| |
| Re: aspectj load-time weaving works for OSGi [message #34626 is a reply to message #34592] |
Thu, 29 January 2004 05:18 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer_REMOVE.ca.ibm.com
done
"Martin Lippert" <lippert@acm.org> wrote in message
news:bv97tt$9s7$1@eclipse.org...
> Hi,
>
> > Can you do what you need to or do you need changes? For now we can hack
to
> > get you going and understand how to do this more elegantly later.
>
> The only change I need is a change in the visibility of the method:
>
> protected void initDynamicImportPackage(ManifestElement[] packages)
>
> in BundleLoader. This is now protected and I would need it to be public
> (to call it from my specialised classloader). I already tried it and it
> works fine with the dynamic import mechanism. Would be wonderful to have
> that in an upcoming milestone release. Thanks again!!!
>
> -Martin
>
>
> >
> > Jeff
> >
> > "Martin Lippert" <lippert@acm.org> wrote in message
> > news:bus9dd$8d5$1@eclipse.org...
> >
> >>Hi,
> >>
> >>
> >>>>>I took a look at the dynamic package import functionality and it
seems
> >>>>>to me that mainly the BundleLoader deals with it. Therefore I don't
> >
> > know
> >
> >>>>>how to add, for example, a new dynamic import to that loader or to
> >>>>>change the setting to "*" at runtime. Did I ignore something?
> >>>>
> >>>>Any idea on that?
> >>>
> >>>Not right now. I'd have to dig through the code to see what is
> >
> > happening
> >
> >>>where. what you say about the BundleLoader sounds right though. Try
> >
> > adding
> >
> >>>something to bundle loader like addDynamicImport(). The implementation
> >>>should be reasonably straightforward. If you can prototype this we can
> >
> > look
> >
> >>>at adding the support for real. Otherwise we are all up to our necks
> >>>preparing for EclipseCon and M7 so cannot be too proactive on
> >
> > non-critical
> >
> >>>items.
> >>
> >>The BundleLoader has a method called "initDynamicImportPackage". This
> >>method could be used to add dynamic imports at runtime, from my point of
> >>view. For that it only has to be set to public visibility.
> >>
> >>The way to access this method (for example from my special adaptor or
> >>class loader) would still be somewhat ugly, but that might be okay (two
> >>ways to access the BundleLoader: cast from Bundle to BundleHost to call
> >>the method getBundleLoader on BundleHost or access the protected field
> >>of BundleClassLoader "delegate" to BundleLoader).
> >>
> >>Does that sounds reasonable?
> >>
> >>Thanks again!
> >>
> >>Best regards,
> >>Martin
> >>
> >
> >
> >
|
|
| | |
| Re: aspectj load-time weaving works for OSGi [message #36869 is a reply to message #36270] |
Thu, 11 March 2004 10:02 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.REMOVE.ca.ibm.com
Sorry for the delay in responding. For some reason my news reader only just
decided to show my your post...
Please enter an enhancement request. #2 looks good/easy.
Jeff
"Martin Lippert" <lippert@acm.org> wrote in message
news:c288tg$pu4$1@eclipse.org...
> Hi,
>
> > Can you do what you need to or do you need changes? For now we can hack
to
> > get you going and understand how to do this more elegantly later.
>
> I observed one problem with my dynamic adding of DynamicImportPackages.
> The list of dynamic imports inside BundleLoader is growing with each
> class that is loaded because the loader does not check if the package
> that is added via initDynamicImportPackage is already in the list of
> dynamic imports. They are always added and I got a huge number of
> duplicates in it. I would like to solve this problem. Therefore I found
> two options:
>
> 1. Make the initDynamicImportPackage method of BundleLoader aware of
> duplicates.
> 2. Make the method isDynamicallyImported of BundleLoader public so that
> I can check if the package is already importet before I call
> initDynamicImportPackage to add it.
>
> I would prefer option 2 since it requires less changes to the code of
> BundleLoader. What do you think?
>
> Thanks!!!
>
> Best regards,
> Martin
>
>
>
>
>
> >
> > Jeff
> >
> > "Martin Lippert" <lippert@acm.org> wrote in message
> > news:bus9dd$8d5$1@eclipse.org...
> >
> >>Hi,
> >>
> >>
> >>>>>I took a look at the dynamic package import functionality and it
seems
> >>>>>to me that mainly the BundleLoader deals with it. Therefore I don't
> >
> > know
> >
> >>>>>how to add, for example, a new dynamic import to that loader or to
> >>>>>change the setting to "*" at runtime. Did I ignore something?
> >>>>
> >>>>Any idea on that?
> >>>
> >>>Not right now. I'd have to dig through the code to see what is
> >
> > happening
> >
> >>>where. what you say about the BundleLoader sounds right though. Try
> >
> > adding
> >
> >>>something to bundle loader like addDynamicImport(). The implementation
> >>>should be reasonably straightforward. If you can prototype this we can
> >
> > look
> >
> >>>at adding the support for real. Otherwise we are all up to our necks
> >>>preparing for EclipseCon and M7 so cannot be too proactive on
> >
> > non-critical
> >
> >>>items.
> >>
> >>The BundleLoader has a method called "initDynamicImportPackage". This
> >>method could be used to add dynamic imports at runtime, from my point of
> >>view. For that it only has to be set to public visibility.
> >>
> >>The way to access this method (for example from my special adaptor or
> >>class loader) would still be somewhat ugly, but that might be okay (two
> >>ways to access the BundleLoader: cast from Bundle to BundleHost to call
> >>the method getBundleLoader on BundleHost or access the protected field
> >>of BundleClassLoader "delegate" to BundleLoader).
> >>
> >>Does that sounds reasonable?
> >>
> >>Thanks again!
> >>
> >>Best regards,
> >>Martin
> >>
> >
> >
> >
|
|
|
| Re: aspectj load-time weaving works for OSGi [message #37070 is a reply to message #36869] |
Thu, 11 March 2004 19:59 |
Martin Lippert
Messages: 124
Registered: July 2009 |
Senior Member |
|
|
Hi,
> Sorry for the delay in responding. For some reason my news reader only just
> decided to show my your post...
>
> Please enter an enhancement request. #2 looks good/easy.
Done. Take a look at:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=54524
Thanks for the support!!!
-Martin
>
> Jeff
>
> "Martin Lippert" <lippert@acm.org> wrote in message
> news:c288tg$pu4$1@eclipse.org...
>
>>Hi,
>>
>>
>>>Can you do what you need to or do you need changes? For now we can hack
>
> to
>
>>>get you going and understand how to do this more elegantly later.
>>
>>I observed one problem with my dynamic adding of DynamicImportPackages.
>>The list of dynamic imports inside BundleLoader is growing with each
>>class that is loaded because the loader does not check if the package
>>that is added via initDynamicImportPackage is already in the list of
>>dynamic imports. They are always added and I got a huge number of
>>duplicates in it. I would like to solve this problem. Therefore I found
>>two options:
>>
>>1. Make the initDynamicImportPackage method of BundleLoader aware of
>>duplicates.
>>2. Make the method isDynamicallyImported of BundleLoader public so that
>>I can check if the package is already importet before I call
>>initDynamicImportPackage to add it.
>>
>>I would prefer option 2 since it requires less changes to the code of
>>BundleLoader. What do you think?
>>
>>Thanks!!!
>>
>>Best regards,
>>Martin
>>
>>
>>
>>
>>
>>
>>>Jeff
>>>
>>>"Martin Lippert" <lippert@acm.org> wrote in message
>>>news:bus9dd$8d5$1@eclipse.org...
>>>
>>>
>>>>Hi,
>>>>
>>>>
>>>>
>>>>>>>I took a look at the dynamic package import functionality and it
>
> seems
>
>>>>>>>to me that mainly the BundleLoader deals with it. Therefore I don't
>>>
>>>know
>>>
>>>
>>>>>>>how to add, for example, a new dynamic import to that loader or to
>>>>>>>change the setting to "*" at runtime. Did I ignore something?
>>>>>>
>>>>>>Any idea on that?
>>>>>
>>>>>Not right now. I'd have to dig through the code to see what is
>>>
>>>happening
>>>
>>>
>>>>>where. what you say about the BundleLoader sounds right though. Try
>>>
>>>adding
>>>
>>>
>>>>>something to bundle loader like addDynamicImport(). The implementation
>>>>>should be reasonably straightforward. If you can prototype this we can
>>>
>>>look
>>>
>>>
>>>>>at adding the support for real. Otherwise we are all up to our necks
>>>>>preparing for EclipseCon and M7 so cannot be too proactive on
>>>
>>>non-critical
>>>
>>>
>>>>>items.
>>>>
>>>>The BundleLoader has a method called "initDynamicImportPackage". This
>>>>method could be used to add dynamic imports at runtime, from my point of
>>>>view. For that it only has to be set to public visibility.
>>>>
>>>>The way to access this method (for example from my special adaptor or
>>>>class loader) would still be somewhat ugly, but that might be okay (two
>>>>ways to access the BundleLoader: cast from Bundle to BundleHost to call
>>>>the method getBundleLoader on BundleHost or access the protected field
>>>>of BundleClassLoader "delegate" to BundleLoader).
>>>>
>>>>Does that sounds reasonable?
>>>>
>>>>Thanks again!
>>>>
>>>>Best regards,
>>>>Martin
>>>>
>>>
>>>
>>>
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 04:21:09 GMT 2024
Powered by FUDForum. Page generated in 0.03689 seconds |
] 
Search
Help
Register
Login
Home
