Home » Eclipse Projects » Equinox » another class loader possible ???
| | | |
| Re: another class loader possible ??? [message #31252 is a reply to message #31181] |
Fri, 19 December 2003 04:22   |
Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.ca.ibm.com
Martin,
The runtime/framework setup is getting more and more open but as you have
seen, we are not quite there yet for the kind of thing you are trying to do.
I believe we will address the bug you posted re: defining different adaptors
though I have to say we are not going to define a supported API right now.
We want to but there are more pressing issues. So it will be "use at your
own risk".
As for how to supply jars to the framework, actually describing that is
pretty easy, there is a system property (osgi.frameworkClasspath) which
defines the classpath of the framework (go figure). By default it includes
the standard 5 or 6 jars in org.eclipse.osgi. That list will change over
time (for example, Eclipse may ship without a console.jar and we may
separate the default and eclipse adaptors more clearly). Technically
speaking, you can add your jar to this list. The elements of the list can
be URLs so your jar can be anywhere. Having it in a bundle is challenging
only in that you have to locate the bundle such that the URL can resolve to
the jar for the adaptor. There is a chicken and egg thing here becaues a
bundle isn't really a bundle until the framework is running and once the
framework is running you are out of luck.
Can you recap, do you really want an adaptor or you just want to have a
different classloader?
Jeff
"Martin Lippert" <lippert@acm.org> wrote in message
news:brjotu$mof$1@eclipse.org...
> Hi,
>
> I learned from Pascal that accessing the EclipseAdaptor from another
> bundle is a really bad idea. Therefore my first thoughts how to hack my
> code into the class loading mechanism were just completely crap.
>
> Pascal suggests to write my own adaptor to do special stuff at class
> loading time. Therefore I am investigating the idea to write a special
> adaptor that is installed instead of the standard EclipseAdaptor class
> to inject a hook at the class loader as well as to publish a service
> that handles the weaving.
>
> I wrote a bug report to make the adaptor instanciation somehow
> parameterizable:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=48695
>
> The remaining question is where to put my weaving and adaptor code. It
> would be great to have it localized into a separate bundle but then this
> bundle needs to be used by the system bundle at startup time to
> instanciate the special adaptor. Any ideas how to deal with this
> situation are welcome!
>
> Best regards,
> Martin
>
>
>
>
>
> >> You found the string... ;-)
> >> I would say that this worth a bug report
> >
> >
> > Okay, that should be no problem.
> >
> > But I run into the next question: Lets assume I would be able to get my
> > own class loader to be used. Does this classloader needs to be part of
> > the org.eclipse.osgi bundle?
> >
> > The reason behind my question is: I would like to use the extension
> > point mechanism in my bytecode transformation stuff. Therefore my
> > mechanism needs to use the runtime bundle somehow. At the same time my
> > special class loader should be able to call the bytecode transformation
> > code.
> >
> > Does this sounds reasonable?
> >
> > - I have to implement a bundle that got started after the runtime but
> > before the application.
> >
> > - This bundle should be able to get called at class loading somehow
> > (maybe by providing a special subclass of EclipseClassLoader).
> >
> > - Therefore this bundle has to be able to set, for example, the
> > EclipseElementFactory at the EclipseAdapter object.
> >
> > What do you mean? Any idea?
> >
> > Best regards,
> > Martin
> >
> >
> >
> >>
> >> PaScaL
> >>
> >> "Martin Lippert" <lippert@acm.org> a
|
|
| |
| Re: another class loader possible ??? [message #31466 is a reply to message #31361] |
Mon, 22 December 2003 18:04 |
 Kevin Duffey
Messages: 304
Registered: July 2009 |
Senior Member |
|
|
Holy crap Martin, how do you become good enough to learn how to mess with
bytecode??!! I thought I knew my stuff by creating a "similar" plugin
engine, but man, messing with bytecode at runtime, and knowing what to
insert where..that is amazing!
"Martin Lippert" <lippert@acm.org> wrote in message
news:bs5ac1$8le$1@eclipse.org...
> Hi,
>
> > The runtime/framework setup is getting more and more open but as you
have
> > seen, we are not quite there yet for the kind of thing you are trying to
do.
> > I believe we will address the bug you posted re: defining different
adaptors
> > though I have to say we are not going to define a supported API right
now.
> > We want to but there are more pressing issues. So it will be "use at
your
> > own risk".
>
> I fully understand that there are more pressing issues right now. I
> would be happy to have a "use at your own risk"-API for that.
>
> > As for how to supply jars to the framework, actually describing that is
> > pretty easy, there is a system property (osgi.frameworkClasspath) which
> > defines the classpath of the framework (go figure). By default it
includes
> > the standard 5 or 6 jars in org.eclipse.osgi. That list will change
over
> > time (for example, Eclipse may ship without a console.jar and we may
> > separate the default and eclipse adaptors more clearly). Technically
> > speaking, you can add your jar to this list. The elements of the list
can
> > be URLs so your jar can be anywhere. Having it in a bundle is
challenging
> > only in that you have to locate the bundle such that the URL can resolve
to
> > the jar for the adaptor. There is a chicken and egg thing here becaues
a
> > bundle isn't really a bundle until the framework is running and once the
> > framework is running you are out of luck.
> >
> > Can you recap, do you really want an adaptor or you just want to have a
> > different classloader?
>
> Let me try to explain what I am trying to achieve:
>
> - I need to modify bytecode at class loading time (to possibly weave
> aspects into each class that is loaded into the system). Therefore I
> implemented a subclass of EclipseClassLoader that reimplements the
> findClassImpl method. Before the loaded bytecode is given to the VM (via
> the call to defineClass) I call a self-implemented service to transform
> the bytecode.
>
> - A reference to the self-implemented service is given to each instance
> of the special class loader via a constructor parameter.
>
> - To create this special class loader I implemented a subclass of
> EclipseElementFactory (which is created by a subclass of EclipseAdaptor).
>
> - My special adaptor also creates the special transformation service via
> an overridden method frameworkStart of EclipseAdaptor.
>
> - I wrote a normal bundle to actually implement the aspect weaving
> functionality at bytecode level. This bundle asks for the transformation
> service at activation and sets a transformer component to the service.
> The service uses that transformer component to actually transform the
> bytecode. This is nice because I can implement the aspect weaving stuff
> in a separated bundle. But the bundle of my special class loader
> (currently org.eclipse.osgi) needs to export my new service package.
>
> - This aspect weaving bundle also defines an extension point for
> aspects. Using this extension point each plugin/bundle of the system is
> able to promote an aspect for weaving (the extension point mechanism is
> a very neat way to do this from my point of view).
>
> - To start this bundle right away at system startup I added it to the
> osgi.bundle property within my special adaptor's frameworkStart method.
>
> I hope that explains my current implementation in an comprehensible way.
> As you can see the main point is that I want to create a special bundle
> that can use the extension point mechanism and which functionality is
> called by a special class loader. And as I understood from Pascal the
> specialized adaptor is the cleanest way to achieve that. I would love to
> create a much simpler solution.
>
> What I haven't solved so far is:
>
> - As a result of the transformation process new dependencies between
> bundles might occur. They need to be added to the delegation model
> between the bundle loaders after the weaving. I am currently trying to
> understand that part of the org.eclipse.osgi bundle but I haven't found
> a way to add imported packages or required bundles to existing bundles
> at runtime.
>
> Any questions and ideas are welcome!!!
>
> Thanks a lot for the help!!!!!!!!!!!!!!!!!!!
>
> Best regards,
> Martin
>
>
|
|
|
| Re: another class loader possible ??? [message #31501 is a reply to message #31361] |
Mon, 22 December 2003 22:19 |
| Eclipse User |
|
|
|
Originally posted by: jeff_mcaffer.ca.ibm.com
Hey Martin,
Sounds good. Seems like you do actually need to have your own adaptor. I
mean, we could parameterize everything in the Eclipse adaptor (e.g., allow
people to define the class of the classloader etc) but that is likely more
work than is strictly needed. If you just implement an adaptor as you
outlined and we make it easier for you to hook that in, we should all be
happy. Agreed?
Jeff
"Martin Lippert" <lippert@acm.org> wrote in message
news:bs5ac1$8le$1@eclipse.org...
> Hi,
>
> > The runtime/framework setup is getting more and more open but as you
have
> > seen, we are not quite there yet for the kind of thing you are trying to
do.
> > I believe we will address the bug you posted re: defining different
adaptors
> > though I have to say we are not going to define a supported API right
now.
> > We want to but there are more pressing issues. So it will be "use at
your
> > own risk".
>
> I fully understand that there are more pressing issues right now. I
> would be happy to have a "use at your own risk"-API for that.
>
> > As for how to supply jars to the framework, actually describing that is
> > pretty easy, there is a system property (osgi.frameworkClasspath) which
> > defines the classpath of the framework (go figure). By default it
includes
> > the standard 5 or 6 jars in org.eclipse.osgi. That list will change
over
> > time (for example, Eclipse may ship without a console.jar and we may
> > separate the default and eclipse adaptors more clearly). Technically
> > speaking, you can add your jar to this list. The elements of the list
can
> > be URLs so your jar can be anywhere. Having it in a bundle is
challenging
> > only in that you have to locate the bundle such that the URL can resolve
to
> > the jar for the adaptor. There is a chicken and egg thing here becaues
a
> > bundle isn't really a bundle until the framework is running and once the
> > framework is running you are out of luck.
> >
> > Can you recap, do you really want an adaptor or you just want to have a
> > different classloader?
>
> Let me try to explain what I am trying to achieve:
>
> - I need to modify bytecode at class loading time (to possibly weave
> aspects into each class that is loaded into the system). Therefore I
> implemented a subclass of EclipseClassLoader that reimplements the
> findClassImpl method. Before the loaded bytecode is given to the VM (via
> the call to defineClass) I call a self-implemented service to transform
> the bytecode.
>
> - A reference to the self-implemented service is given to each instance
> of the special class loader via a constructor parameter.
>
> - To create this special class loader I implemented a subclass of
> EclipseElementFactory (which is created by a subclass of EclipseAdaptor).
>
> - My special adaptor also creates the special transformation service via
> an overridden method frameworkStart of EclipseAdaptor.
>
> - I wrote a normal bundle to actually implement the aspect weaving
> functionality at bytecode level. This bundle asks for the transformation
> service at activation and sets a transformer component to the service.
> The service uses that transformer component to actually transform the
> bytecode. This is nice because I can implement the aspect weaving stuff
> in a separated bundle. But the bundle of my special class loader
> (currently org.eclipse.osgi) needs to export my new service package.
>
> - This aspect weaving bundle also defines an extension point for
> aspects. Using this extension point each plugin/bundle of the system is
> able to promote an aspect for weaving (the extension point mechanism is
> a very neat way to do this from my point of view).
>
> - To start this bundle right away at system startup I added it to the
> osgi.bundle property within my special adaptor's frameworkStart method.
>
> I hope that explains my current implementation in an comprehensible way.
> As you can see the main point is that I want to create a special bundle
> that can use the extension point mechanism and which functionality is
> called by a special class loader. And as I understood from Pascal the
> specialized adaptor is the cleanest way to achieve that. I would love to
> create a much simpler solution.
>
> What I haven't solved so far is:
>
> - As a result of the transformation process new dependencies between
> bundles might occur. They need to be added to the delegation model
> between the bundle loaders after the weaving. I am currently trying to
> understand that part of the org.eclipse.osgi bundle but I haven't found
> a way to add imported packages or required bundles to existing bundles
> at runtime.
>
> Any questions and ideas are welcome!!!
>
> Thanks a lot for the help!!!!!!!!!!!!!!!!!!!
>
> Best regards,
> Martin
>
>
|
|
|
| Re: another class loader possible ??? [message #31571 is a reply to message #31501] |
Tue, 23 December 2003 10:04 |
Martin Lippert
Messages: 124
Registered: July 2009 |
Senior Member |
|
|
Hi Jeff,
> Sounds good. Seems like you do actually need to have your own adaptor. I
> mean, we could parameterize everything in the Eclipse adaptor (e.g., allow
> people to define the class of the classloader etc) but that is likely more
> work than is strictly needed. If you just implement an adaptor as you
> outlined and we make it easier for you to hook that in, we should all be
> happy. Agreed?
Completely. :-)
There is only one problem left for which I haven't found a solution
until now. I have to add dependencies between plugins/bundles at
runtime. This happens, for example, if a class is woven with some
aspect. Then a new dependency between the woven class bundle and the
aspects bundle exists as well as a dependency between the woven class
bundle and the weaving bundle because of some base libraries that are
now used inside the woven class.
I haven't found a clean way to realize this. The dependencies between
the bundles are hidden inside the BundleLoader and the BundleLoader does
not provide any methods to add, for example, a required bundle at
runtime. And I haven't found a way to get a subclass of BundleLoader
instanciated instead of the original one.
I could add this additional depencencies to my special class loader.
This would mean that my class loader collects dependent loaders from
dynamically added bundles (similar to DelegatingURLClassLoader from
Eclipse 2.1). But even in this case I haven't found a clean way to ask
for the real class loader of a bundle (maybe I can use the compatibility
layer and the PluginClassLoader).
Do you have any idea how to solve this problem?
Thanks again for the help, support, and feedback.
Best regards,
Martin
>
> Jeff
>
> "Martin Lippert" <lippert@acm.org> wrote in message
> news:bs5ac1$8le$1@eclipse.org...
>
>>Hi,
>>
>>
>>>The runtime/framework setup is getting more and more open but as you
>
> have
>
>>>seen, we are not quite there yet for the kind of thing you are trying to
>
> do.
>
>>>I believe we will address the bug you posted re: defining different
>
> adaptors
>
>>>though I have to say we are not going to define a supported API right
>
> now.
>
>>>We want to but there are more pressing issues. So it will be "use at
>
> your
>
>>>own risk".
>>
>>I fully understand that there are more pressing issues right now. I
>>would be happy to have a "use at your own risk"-API for that.
>>
>>
>>>As for how to supply jars to the framework, actually describing that is
>>>pretty easy, there is a system property (osgi.frameworkClasspath) which
>>>defines the classpath of the framework (go figure). By default it
>
> includes
>
>>>the standard 5 or 6 jars in org.eclipse.osgi. That list will change
>
> over
>
>>>time (for example, Eclipse may ship without a console.jar and we may
>>>separate the default and eclipse adaptors more clearly). Technically
>>>speaking, you can add your jar to this list. The elements of the list
>
> can
>
>>>be URLs so your jar can be anywhere. Having it in a bundle is
>
> challenging
>
>>>only in that you have to locate the bundle such that the URL can resolve
>
> to
>
>>>the jar for the adaptor. There is a chicken and egg thing here becaues
>
> a
>
>>>bundle isn't really a bundle until the framework is running and once the
>>>framework is running you are out of luck.
>>>
>>>Can you recap, do you really want an adaptor or you just want to have a
>>>different classloader?
>>
>>Let me try to explain what I am trying to achieve:
>>
>>- I need to modify bytecode at class loading time (to possibly weave
>>aspects into each class that is loaded into the system). Therefore I
>>implemented a subclass of EclipseClassLoader that reimplements the
>>findClassImpl method. Before the loaded bytecode is given to the VM (via
>>the call to defineClass) I call a self-implemented service to transform
>>the bytecode.
>>
>>- A reference to the self-implemented service is given to each instance
>>of the special class loader via a constructor parameter.
>>
>>- To create this special class loader I implemented a subclass of
>>EclipseElementFactory (which is created by a subclass of EclipseAdaptor).
>>
>>- My special adaptor also creates the special transformation service via
>>an overridden method frameworkStart of EclipseAdaptor.
>>
>>- I wrote a normal bundle to actually implement the aspect weaving
>>functionality at bytecode level. This bundle asks for the transformation
>>service at activation and sets a transformer component to the service.
>>The service uses that transformer component to actually transform the
>>bytecode. This is nice because I can implement the aspect weaving stuff
>>in a separated bundle. But the bundle of my special class loader
>>(currently org.eclipse.osgi) needs to export my new service package.
>>
>>- This aspect weaving bundle also defines an extension point for
>>aspects. Using this extension point each plugin/bundle of the system is
>>able to promote an aspect for weaving (the extension point mechanism is
>>a very neat way to do this from my point of view).
>>
>>- To start this bundle right away at system startup I added it to the
>>osgi.bundle property within my special adaptor's frameworkStart method.
>>
>>I hope that explains my current implementation in an comprehensible way.
>>As you can see the main point is that I want to create a special bundle
>>that can use the extension point mechanism and which functionality is
>>called by a special class loader. And as I understood from Pascal the
>>specialized adaptor is the cleanest way to achieve that. I would love to
>>create a much simpler solution.
>>
>>What I haven't solved so far is:
>>
>>- As a result of the transformation process new dependencies between
>>bundles might occur. They need to be added to the delegation model
>>between the bundle loaders after the weaving. I am currently trying to
>>understand that part of the org.eclipse.osgi bundle but I haven't found
>>a way to add imported packages or required bundles to existing bundles
>>at runtime.
>>
>>Any questions and ideas are welcome!!!
>>
>>Thanks a lot for the help!!!!!!!!!!!!!!!!!!!
>>
>>Best regards,
>>Martin
>>
>>
>
>
>
|
|
|
| Re: another class loader possible ??? [message #31606 is a reply to message #31466] |
Tue, 23 December 2003 11:53 |
Martin Lippert
Messages: 124
Registered: July 2009 |
Senior Member |
|
|
Hey,
> Holy crap Martin, how do you become good enough to learn how to mess with
> bytecode??!! I thought I knew my stuff by creating a "similar" plugin
> engine, but man, messing with bytecode at runtime, and knowing what to
> insert where..that is amazing!
Thanks for the commend but it completely belongs to the AspectJ team. I
am just using their bytecode weaving implementation to do these kind of
things.
Merry Christmas,
Martin
>
> "Martin Lippert" <lippert@acm.org> wrote in message
> news:bs5ac1$8le$1@eclipse.org...
>
>>Hi,
>>
>>
>>>The runtime/framework setup is getting more and more open but as you
>
> have
>
>>>seen, we are not quite there yet for the kind of thing you are trying to
>
> do.
>
>>>I believe we will address the bug you posted re: defining different
>
> adaptors
>
>>>though I have to say we are not going to define a supported API right
>
> now.
>
>>>We want to but there are more pressing issues. So it will be "use at
>
> your
>
>>>own risk".
>>
>>I fully understand that there are more pressing issues right now. I
>>would be happy to have a "use at your own risk"-API for that.
>>
>>
>>>As for how to supply jars to the framework, actually describing that is
>>>pretty easy, there is a system property (osgi.frameworkClasspath) which
>>>defines the classpath of the framework (go figure). By default it
>
> includes
>
>>>the standard 5 or 6 jars in org.eclipse.osgi. That list will change
>
> over
>
>>>time (for example, Eclipse may ship without a console.jar and we may
>>>separate the default and eclipse adaptors more clearly). Technically
>>>speaking, you can add your jar to this list. The elements of the list
>
> can
>
>>>be URLs so your jar can be anywhere. Having it in a bundle is
>
> challenging
>
>>>only in that you have to locate the bundle such that the URL can resolve
>
> to
>
>>>the jar for the adaptor. There is a chicken and egg thing here becaues
>
> a
>
>>>bundle isn't really a bundle until the framework is running and once the
>>>framework is running you are out of luck.
>>>
>>>Can you recap, do you really want an adaptor or you just want to have a
>>>different classloader?
>>
>>Let me try to explain what I am trying to achieve:
>>
>>- I need to modify bytecode at class loading time (to possibly weave
>>aspects into each class that is loaded into the system). Therefore I
>>implemented a subclass of EclipseClassLoader that reimplements the
>>findClassImpl method. Before the loaded bytecode is given to the VM (via
>>the call to defineClass) I call a self-implemented service to transform
>>the bytecode.
>>
>>- A reference to the self-implemented service is given to each instance
>>of the special class loader via a constructor parameter.
>>
>>- To create this special class loader I implemented a subclass of
>>EclipseElementFactory (which is created by a subclass of EclipseAdaptor).
>>
>>- My special adaptor also creates the special transformation service via
>>an overridden method frameworkStart of EclipseAdaptor.
>>
>>- I wrote a normal bundle to actually implement the aspect weaving
>>functionality at bytecode level. This bundle asks for the transformation
>>service at activation and sets a transformer component to the service.
>>The service uses that transformer component to actually transform the
>>bytecode. This is nice because I can implement the aspect weaving stuff
>>in a separated bundle. But the bundle of my special class loader
>>(currently org.eclipse.osgi) needs to export my new service package.
>>
>>- This aspect weaving bundle also defines an extension point for
>>aspects. Using this extension point each plugin/bundle of the system is
>>able to promote an aspect for weaving (the extension point mechanism is
>>a very neat way to do this from my point of view).
>>
>>- To start this bundle right away at system startup I added it to the
>>osgi.bundle property within my special adaptor's frameworkStart method.
>>
>>I hope that explains my current implementation in an comprehensible way.
>>As you can see the main point is that I want to create a special bundle
>>that can use the extension point mechanism and which functionality is
>>called by a special class loader. And as I understood from Pascal the
>>specialized adaptor is the cleanest way to achieve that. I would love to
>>create a much simpler solution.
>>
>>What I haven't solved so far is:
>>
>>- As a result of the transformation process new dependencies between
>>bundles might occur. They need to be added to the delegation model
>>between the bundle loaders after the weaving. I am currently trying to
>>understand that part of the org.eclipse.osgi bundle but I haven't found
>>a way to add imported packages or required bundles to existing bundles
>>at runtime.
>>
>>Any questions and ideas are welcome!!!
>>
>>Thanks a lot for the help!!!!!!!!!!!!!!!!!!!
>>
>>Best regards,
>>Martin
>>
>>
>
>
>
|
|
|
Goto Forum:
Current Time: Tue Apr 23 13:17:24 GMT 2024
Powered by FUDForum. Page generated in 0.02705 seconds |
] 
Search
Help
Register
Login
Home
