You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by santillan <sa...@dit.upm.es> on 2006/09/09 18:18:49 UTC
JMX introspector
I've added a new module to the repo: jmxintrospector. It enables the dynamic
generation of proxies to remote objects without having the interfaces in the
classpath. I wanted to check with you if there were any licensig issues with
it, because it uses the Javassist library. Javassist is both Mozilla (MPL)
and LGPL licensed (it is part of JBoss, BTW). It uses it unmodified. In
order to use it, it has to be manually downloaded (version 3.3 not available
in the repos yet) and installed to the local M2_REPO, and the readme file
includes references to it, so I think it's ok but I'd rather ask you guys
anyway just in case.
By the way, would it be possible to define a JMood component at JIRA to
track its issues, or should I use the "unknown" category?
Cheers!!!
//manuel
--
Manuel Santillán <sa...@dit.upm.es>
http://www.dit.upm.es/santillan
Departamento de Ingeniería de Sistemas Telemáticos
Escuela Técnica Superior de Ingenieros de Telecomunicación
Universidad Politécnica de Madrid
Avda. Complutense, s/n
28040 Madrid SPAIN
Tel. +34 913367366 ext.3034
Re: OSGi URL to file
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 14 September 2006 11:04, Richard S. Hall wrote:
> Great. Then it is nice to know that it can be done by a separate bundle.
> Perhaps Equinox should package it up separately so that it can be used
> on other frameworks. :-)
Yipee... more decoupling, smaller framework ;o)
more need for bundle management solutions...
Cheers
Niclas
Re: OSGi URL to file
Posted by Erik Bengtson <er...@jpox.org>.
Hi,
The FileLocator working for other frameworks would be just great for the moment,
since I have a workaround for the classloading problem.
The workaround runs on application startup which verifies whether some classes
have been "enhanced" (more explicitly, a JDO/JPA implementation that enhance
persistent classes), and if they have not been enhanced the enhancer is
invoked. An application restart is done after that if needed.
I could also try to reinstall the bundle without restarting, but I did not get
that far.
Should I raise a feature request in equinox project regarding the FileLocator?
Thanks,
Erik Bengtson
Quoting Thomas Watson <tj...@us.ibm.com>:
> One thing to note is that the files are versioned just like native code
> in a bundle. When a bundle is updated then we need to extract the new
> files to a cache. Since the framework already knows how to do this for
> native code it was natural for the framework to provide a general
> facility for other files in a bundle.
>
> We can certainly write a FileLocator that works on other frameworks, but
> it will have to do the same kind of accounting that the framework
> already does to make sure the latest content is extracted to a cache.
>
> This is certainly feasible, but I wanted to point out why we have done
> it this way. On other frameworks we would have to write a
> URLConverter service that understands the protocols that
> framework uses for bundle resources and do the proper extracting.
> Then FileLocator would use that URLConverter to convert bundle
> resource URLs to file URLs.
>
> In Equinox we just happen to publish this URLConverter service from
> the system bundle.
>
> Tom.
>
> P.S. In another post I saw that Erik wanted to use this to get access
> to a class file and then modify the bits of the class. This will not
> work because the extracted file is not used to load a class at
> runtime. There are various AspectJ projects looking at
> doing load time weaving in OSGi and as Richard points out
> CPEG is looking into this for future specifications. For example:
>
> http://www.eclipse.org/equinox/incubator/aspects/index.php
>
> "Richard S. Hall" <he...@ungoverned.org> wrote on 09/13/2006 10:04:35 PM:
>
> > Great. Then it is nice to know that it can be done by a separate bundle.
>
> > Perhaps Equinox should package it up separately so that it can be used
> > on other frameworks. :-)
> >
> > -> richard
> >
> > Jeff McAffer wrote:
> > > I'm not sure I would call it "baked in". FileLocator itself is just a
>
> > > helper that aquires a "URLConverter" service. It happens that that
> > > service is provided by the system bundle since it is the same code
> that is
> > > used by the framework to do nested JAR and native code extraction.
> Your
> > > characterization of the processing is exactly what the service does.
> > >
> > > Jeff
> > >
> > >
> > >
> > >
> > > "Richard S. Hall" <he...@ungoverned.org>
> > > 09/13/2006 10:17 PM
> > > Please respond to
> > > felix-dev@incubator.apache.org
> > >
> > >
> > > To
> > > felix-dev@incubator.apache.org
> > > cc
> > >
> > > Subject
> > > Re: OSGi URL to file
> > >
> > >
> > >
> > >
> > >
> > >
> > > Jeff McAffer wrote:
> > >
> > >> In practice this takes things that you would get back from
> getResource
> > >>
> > > or
> > >
> > >> getEntry and converts them to file:. In the case of a directory
> based
> > >> bundle, the file is likely already directly in the filesystem so its
> > >>
> > > file:
> > >
> > >> url is returned. In the case of a JAR'd bundle, the file (or
> directory)
> > >>
> > >
> > >
> > >> is extracted to a cache and that location returned.
> > >>
> > >>
> > >
> > > If that's the case, then why not just write a simple utility library
> > > bundle that provides the code to do this? It doesn't seem like it
> needs
> > > to be baked into the framework. Simply check to see if the URL is a
> > > file, if so you are done, if not, then copy the resource to the
> bundle's
> > > private area and return that file.
> > >
> > > -> richard
> > >
> > >
> > >> Jeff
> > >>
> > >>
> > >>
> > >>
> > >> "Richard S. Hall" <he...@ungoverned.org>
> > >> 09/13/2006 07:52 PM
> > >> Please respond to
> > >> felix-dev@incubator.apache.org
> > >>
> > >>
> > >> To
> > >> felix-dev@incubator.apache.org
> > >> cc
> > >>
> > >> Subject
> > >> Re: OSGi URL to file
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> No, there is no standard way, nor any equivalent method in Felix.
> > >>
> > >> This is something you could construct for Felix, perhaps, but it
> seems
> > >> like bad form since the whole point of getResource() is to eliminate
> the
> > >>
> > >
> > >
> > >> dependencies on file locations.
> > >>
> > >> And what happens if the resource is in a JAR file, then it will never
> be
> > >>
> > >
> > >
> > >> a file: resource?
> > >>
> > >> You might be trying to do something and this is the only way to do
> it,
> > >> but it would certainly be better if there was another way.
> > >>
> > >> -> richard
> > >>
> > >> Erik Bengtson wrote:
> > >>
> > >>
> > >>> Hi,
> > >>>
> > >>> I need to convert the URL given by
> > >>> URL url =
> > >>>
> > >>>
> > >>>
> > >
> Bundle.loadClass('something').getClassLoader().getResource('anotherthing');
> > >
> > >>> Using equinox I get "bundleresource://" protocol, so I want to
> convert
> > >>>
> > >>>
> > >> to
> > >>
> > >>
> > >>> file://.
> > >>>
> > >>> To convert I use:
> > >>>
> > >>> URL fileURL = org.eclipse.core.runtime.FileLocator.toFileURL(url);
> > >>>
> > >>> Is there an Felix equivalent or in the OSGI standard?
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Erik Bengtson
> > >>>
> > >>>
> > >>> PS:
> > >>> Richard,
> > >>>
> > >>> thanks for the previous answer regarding best pratices on
> dependencies.
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> > >
> > >
>
Re: OSGi URL to file
Posted by Thomas Watson <tj...@us.ibm.com>.
One thing to note is that the files are versioned just like native code
in a bundle. When a bundle is updated then we need to extract the new
files to a cache. Since the framework already knows how to do this for
native code it was natural for the framework to provide a general
facility for other files in a bundle.
We can certainly write a FileLocator that works on other frameworks, but
it will have to do the same kind of accounting that the framework
already does to make sure the latest content is extracted to a cache.
This is certainly feasible, but I wanted to point out why we have done
it this way. On other frameworks we would have to write a
URLConverter service that understands the protocols that
framework uses for bundle resources and do the proper extracting.
Then FileLocator would use that URLConverter to convert bundle
resource URLs to file URLs.
In Equinox we just happen to publish this URLConverter service from
the system bundle.
Tom.
P.S. In another post I saw that Erik wanted to use this to get access
to a class file and then modify the bits of the class. This will not
work because the extracted file is not used to load a class at
runtime. There are various AspectJ projects looking at
doing load time weaving in OSGi and as Richard points out
CPEG is looking into this for future specifications. For example:
http://www.eclipse.org/equinox/incubator/aspects/index.php
"Richard S. Hall" <he...@ungoverned.org> wrote on 09/13/2006 10:04:35 PM:
> Great. Then it is nice to know that it can be done by a separate bundle.
> Perhaps Equinox should package it up separately so that it can be used
> on other frameworks. :-)
>
> -> richard
>
> Jeff McAffer wrote:
> > I'm not sure I would call it "baked in". FileLocator itself is just a
> > helper that aquires a "URLConverter" service. It happens that that
> > service is provided by the system bundle since it is the same code
that is
> > used by the framework to do nested JAR and native code extraction.
Your
> > characterization of the processing is exactly what the service does.
> >
> > Jeff
> >
> >
> >
> >
> > "Richard S. Hall" <he...@ungoverned.org>
> > 09/13/2006 10:17 PM
> > Please respond to
> > felix-dev@incubator.apache.org
> >
> >
> > To
> > felix-dev@incubator.apache.org
> > cc
> >
> > Subject
> > Re: OSGi URL to file
> >
> >
> >
> >
> >
> >
> > Jeff McAffer wrote:
> >
> >> In practice this takes things that you would get back from
getResource
> >>
> > or
> >
> >> getEntry and converts them to file:. In the case of a directory
based
> >> bundle, the file is likely already directly in the filesystem so its
> >>
> > file:
> >
> >> url is returned. In the case of a JAR'd bundle, the file (or
directory)
> >>
> >
> >
> >> is extracted to a cache and that location returned.
> >>
> >>
> >
> > If that's the case, then why not just write a simple utility library
> > bundle that provides the code to do this? It doesn't seem like it
needs
> > to be baked into the framework. Simply check to see if the URL is a
> > file, if so you are done, if not, then copy the resource to the
bundle's
> > private area and return that file.
> >
> > -> richard
> >
> >
> >> Jeff
> >>
> >>
> >>
> >>
> >> "Richard S. Hall" <he...@ungoverned.org>
> >> 09/13/2006 07:52 PM
> >> Please respond to
> >> felix-dev@incubator.apache.org
> >>
> >>
> >> To
> >> felix-dev@incubator.apache.org
> >> cc
> >>
> >> Subject
> >> Re: OSGi URL to file
> >>
> >>
> >>
> >>
> >>
> >>
> >> No, there is no standard way, nor any equivalent method in Felix.
> >>
> >> This is something you could construct for Felix, perhaps, but it
seems
> >> like bad form since the whole point of getResource() is to eliminate
the
> >>
> >
> >
> >> dependencies on file locations.
> >>
> >> And what happens if the resource is in a JAR file, then it will never
be
> >>
> >
> >
> >> a file: resource?
> >>
> >> You might be trying to do something and this is the only way to do
it,
> >> but it would certainly be better if there was another way.
> >>
> >> -> richard
> >>
> >> Erik Bengtson wrote:
> >>
> >>
> >>> Hi,
> >>>
> >>> I need to convert the URL given by
> >>> URL url =
> >>>
> >>>
> >>>
> >
Bundle.loadClass('something').getClassLoader().getResource('anotherthing');
> >
> >>> Using equinox I get "bundleresource://" protocol, so I want to
convert
> >>>
> >>>
> >> to
> >>
> >>
> >>> file://.
> >>>
> >>> To convert I use:
> >>>
> >>> URL fileURL = org.eclipse.core.runtime.FileLocator.toFileURL(url);
> >>>
> >>> Is there an Felix equivalent or in the OSGI standard?
> >>>
> >>> Thanks,
> >>>
> >>> Erik Bengtson
> >>>
> >>>
> >>> PS:
> >>> Richard,
> >>>
> >>> thanks for the previous answer regarding best pratices on
dependencies.
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
Re: OSGi URL to file
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Great. Then it is nice to know that it can be done by a separate bundle.
Perhaps Equinox should package it up separately so that it can be used
on other frameworks. :-)
-> richard
Jeff McAffer wrote:
> I'm not sure I would call it "baked in". FileLocator itself is just a
> helper that aquires a "URLConverter" service. It happens that that
> service is provided by the system bundle since it is the same code that is
> used by the framework to do nested JAR and native code extraction. Your
> characterization of the processing is exactly what the service does.
>
> Jeff
>
>
>
>
> "Richard S. Hall" <he...@ungoverned.org>
> 09/13/2006 10:17 PM
> Please respond to
> felix-dev@incubator.apache.org
>
>
> To
> felix-dev@incubator.apache.org
> cc
>
> Subject
> Re: OSGi URL to file
>
>
>
>
>
>
> Jeff McAffer wrote:
>
>> In practice this takes things that you would get back from getResource
>>
> or
>
>> getEntry and converts them to file:. In the case of a directory based
>> bundle, the file is likely already directly in the filesystem so its
>>
> file:
>
>> url is returned. In the case of a JAR'd bundle, the file (or directory)
>>
>
>
>> is extracted to a cache and that location returned.
>>
>>
>
> If that's the case, then why not just write a simple utility library
> bundle that provides the code to do this? It doesn't seem like it needs
> to be baked into the framework. Simply check to see if the URL is a
> file, if so you are done, if not, then copy the resource to the bundle's
> private area and return that file.
>
> -> richard
>
>
>> Jeff
>>
>>
>>
>>
>> "Richard S. Hall" <he...@ungoverned.org>
>> 09/13/2006 07:52 PM
>> Please respond to
>> felix-dev@incubator.apache.org
>>
>>
>> To
>> felix-dev@incubator.apache.org
>> cc
>>
>> Subject
>> Re: OSGi URL to file
>>
>>
>>
>>
>>
>>
>> No, there is no standard way, nor any equivalent method in Felix.
>>
>> This is something you could construct for Felix, perhaps, but it seems
>> like bad form since the whole point of getResource() is to eliminate the
>>
>
>
>> dependencies on file locations.
>>
>> And what happens if the resource is in a JAR file, then it will never be
>>
>
>
>> a file: resource?
>>
>> You might be trying to do something and this is the only way to do it,
>> but it would certainly be better if there was another way.
>>
>> -> richard
>>
>> Erik Bengtson wrote:
>>
>>
>>> Hi,
>>>
>>> I need to convert the URL given by
>>> URL url =
>>>
>>>
>>>
> Bundle.loadClass('something').getClassLoader().getResource('anotherthing');
>
>>> Using equinox I get "bundleresource://" protocol, so I want to convert
>>>
>>>
>> to
>>
>>
>>> file://.
>>>
>>> To convert I use:
>>>
>>> URL fileURL = org.eclipse.core.runtime.FileLocator.toFileURL(url);
>>>
>>> Is there an Felix equivalent or in the OSGI standard?
>>>
>>> Thanks,
>>>
>>> Erik Bengtson
>>>
>>>
>>> PS:
>>> Richard,
>>>
>>> thanks for the previous answer regarding best pratices on dependencies.
>>>
>>>
>>>
>>
>>
>
>
>
Re: OSGi URL to file
Posted by Jeff McAffer <Je...@ca.ibm.com>.
I'm not sure I would call it "baked in". FileLocator itself is just a
helper that aquires a "URLConverter" service. It happens that that
service is provided by the system bundle since it is the same code that is
used by the framework to do nested JAR and native code extraction. Your
characterization of the processing is exactly what the service does.
Jeff
"Richard S. Hall" <he...@ungoverned.org>
09/13/2006 10:17 PM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: OSGi URL to file
Jeff McAffer wrote:
> In practice this takes things that you would get back from getResource
or
> getEntry and converts them to file:. In the case of a directory based
> bundle, the file is likely already directly in the filesystem so its
file:
> url is returned. In the case of a JAR'd bundle, the file (or directory)
> is extracted to a cache and that location returned.
>
If that's the case, then why not just write a simple utility library
bundle that provides the code to do this? It doesn't seem like it needs
to be baked into the framework. Simply check to see if the URL is a
file, if so you are done, if not, then copy the resource to the bundle's
private area and return that file.
-> richard
> Jeff
>
>
>
>
> "Richard S. Hall" <he...@ungoverned.org>
> 09/13/2006 07:52 PM
> Please respond to
> felix-dev@incubator.apache.org
>
>
> To
> felix-dev@incubator.apache.org
> cc
>
> Subject
> Re: OSGi URL to file
>
>
>
>
>
>
> No, there is no standard way, nor any equivalent method in Felix.
>
> This is something you could construct for Felix, perhaps, but it seems
> like bad form since the whole point of getResource() is to eliminate the
> dependencies on file locations.
>
> And what happens if the resource is in a JAR file, then it will never be
> a file: resource?
>
> You might be trying to do something and this is the only way to do it,
> but it would certainly be better if there was another way.
>
> -> richard
>
> Erik Bengtson wrote:
>
>> Hi,
>>
>> I need to convert the URL given by
>> URL url =
>>
>>
>
Bundle.loadClass('something').getClassLoader().getResource('anotherthing');
>
>> Using equinox I get "bundleresource://" protocol, so I want to convert
>>
> to
>
>> file://.
>>
>> To convert I use:
>>
>> URL fileURL = org.eclipse.core.runtime.FileLocator.toFileURL(url);
>>
>> Is there an Felix equivalent or in the OSGI standard?
>>
>> Thanks,
>>
>> Erik Bengtson
>>
>>
>> PS:
>> Richard,
>>
>> thanks for the previous answer regarding best pratices on dependencies.
>>
>>
>
>
>
Re: OSGi URL to file
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Jeff McAffer wrote:
> In practice this takes things that you would get back from getResource or
> getEntry and converts them to file:. In the case of a directory based
> bundle, the file is likely already directly in the filesystem so its file:
> url is returned. In the case of a JAR'd bundle, the file (or directory)
> is extracted to a cache and that location returned.
>
If that's the case, then why not just write a simple utility library
bundle that provides the code to do this? It doesn't seem like it needs
to be baked into the framework. Simply check to see if the URL is a
file, if so you are done, if not, then copy the resource to the bundle's
private area and return that file.
-> richard
> Jeff
>
>
>
>
> "Richard S. Hall" <he...@ungoverned.org>
> 09/13/2006 07:52 PM
> Please respond to
> felix-dev@incubator.apache.org
>
>
> To
> felix-dev@incubator.apache.org
> cc
>
> Subject
> Re: OSGi URL to file
>
>
>
>
>
>
> No, there is no standard way, nor any equivalent method in Felix.
>
> This is something you could construct for Felix, perhaps, but it seems
> like bad form since the whole point of getResource() is to eliminate the
> dependencies on file locations.
>
> And what happens if the resource is in a JAR file, then it will never be
> a file: resource?
>
> You might be trying to do something and this is the only way to do it,
> but it would certainly be better if there was another way.
>
> -> richard
>
> Erik Bengtson wrote:
>
>> Hi,
>>
>> I need to convert the URL given by
>> URL url =
>>
>>
> Bundle.loadClass('something').getClassLoader().getResource('anotherthing');
>
>> Using equinox I get "bundleresource://" protocol, so I want to convert
>>
> to
>
>> file://.
>>
>> To convert I use:
>>
>> URL fileURL = org.eclipse.core.runtime.FileLocator.toFileURL(url);
>>
>> Is there an Felix equivalent or in the OSGI standard?
>>
>> Thanks,
>>
>> Erik Bengtson
>>
>>
>> PS:
>> Richard,
>>
>> thanks for the previous answer regarding best pratices on dependencies.
>>
>>
>
>
>
Re: OSGi URL to file
Posted by Jeff McAffer <Je...@ca.ibm.com>.
Hmmm, yes, this is a different problem. Even in Equinox I would be
surprised if toFileURL was helping you since you then have to get the
modified class file on the classpath of the bundle's classloader (unless
of course you are using your own classloader). A better approach is as
Richard says, built in bytecode modification facilities. We have various
hooks in Equinox and it can likely be done in Felix and other frameworks
but there is no standard in the area.
Jeff
"Richard S. Hall" <he...@ungoverned.org>
09/14/2006 12:43 AM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: OSGi URL to file
Erik Bengtson wrote:
> My use case is the following:
>
> I want to modify the bytecode of some classes at runtime.
>
> I thought that I could get a url.getConnection().getOutputStream() to do
that,
> but it does not seems to work (sort of non supported protocol).
>
Providing better support for byte code manipulation is a topic of
discussion inside CPEG...
-> richard
> Thanks Jeff and Richard again for the reponses.
>
>
> Quoting Jeff McAffer <Je...@ca.ibm.com>:
>
>
>> yes, the usecases for this are somewhat rare but they do come up. Most
of
>> the time it relates to bundles that supply files to non-OSGi aware
>> systems. For example:
>> - a bundle that supplies an executable that is in turn exec()'d by the
>> bundle. The executalbe must be directly in the filesystem since the OS
>> does not know how to read JARs. Native headers don't do it for you
since
>> you actually need the real path fo the executable in the file system
>> - a bundle that supplies content to a browser. A help or doc system
for
>> exampe. Again, the browser does not know how to look into JARs so the
>> content must be directly in the filesystem and you need a file: url to
>> pass to the browser
>>
>> We've seen both of these (and more) in Eclipse and so added the
>> FileLocator.toFileURL() helper method Erik mentioned. Here is the
>> Javadoc
>>
>> /**
>> * Converts a URL that uses a user-defined protocol into a URL
>> that uses the file
>> * protocol. The contents of the URL may be extracted into a
cache
>> on the file-system
>> * in order to get a file URL.
>> * <p>
>> * If the protocol for the given URL is not recognized by this
>> converter, the original
>> * URL is returned as-is.
>> * </p>
>> * @param url the original URL
>> * @return the converted file URL or the original URL passed in
if
>> it is
>> * not recognized by this converter
>> * @throws IOException if an error occurs during the conversion
>> */
>>
>> In practice this takes things that you would get back from getResource
or
>> getEntry and converts them to file:. In the case of a directory based
>> bundle, the file is likely already directly in the filesystem so its
file:
>> url is returned. In the case of a JAR'd bundle, the file (or
directory)
>> is extracted to a cache and that location returned.
>>
>> Jeff
>>
>>
>>
>>
>> "Richard S. Hall" <he...@ungoverned.org>
>> 09/13/2006 07:52 PM
>> Please respond to
>> felix-dev@incubator.apache.org
>>
>>
>> To
>> felix-dev@incubator.apache.org
>> cc
>>
>> Subject
>> Re: OSGi URL to file
>>
>>
>>
>>
>>
>>
>> No, there is no standard way, nor any equivalent method in Felix.
>>
>> This is something you could construct for Felix, perhaps, but it seems
>> like bad form since the whole point of getResource() is to eliminate
the
>> dependencies on file locations.
>>
>> And what happens if the resource is in a JAR file, then it will never
be
>> a file: resource?
>>
>> You might be trying to do something and this is the only way to do it,
>> but it would certainly be better if there was another way.
>>
>> -> richard
>>
>> Erik Bengtson wrote:
>>
>>> Hi,
>>>
>>> I need to convert the URL given by
>>> URL url =
>>>
>>>
>>
Bundle.loadClass('something').getClassLoader().getResource('anotherthing');
>>
>>> Using equinox I get "bundleresource://" protocol, so I want to convert
>>>
>> to
>>
>>> file://.
>>>
>>> To convert I use:
>>>
>>> URL fileURL = org.eclipse.core.runtime.FileLocator.toFileURL(url);
>>>
>>> Is there an Felix equivalent or in the OSGI standard?
>>>
>>> Thanks,
>>>
>>> Erik Bengtson
>>>
>>>
>>> PS:
>>> Richard,
>>>
>>> thanks for the previous answer regarding best pratices on
dependencies.
>>>
>>>
>>
>
>
>
>
Re: OSGi URL to file
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Erik Bengtson wrote:
> My use case is the following:
>
> I want to modify the bytecode of some classes at runtime.
>
> I thought that I could get a url.getConnection().getOutputStream() to do that,
> but it does not seems to work (sort of non supported protocol).
>
Providing better support for byte code manipulation is a topic of
discussion inside CPEG...
-> richard
> Thanks Jeff and Richard again for the reponses.
>
>
> Quoting Jeff McAffer <Je...@ca.ibm.com>:
>
>
>> yes, the usecases for this are somewhat rare but they do come up. Most of
>> the time it relates to bundles that supply files to non-OSGi aware
>> systems. For example:
>> - a bundle that supplies an executable that is in turn exec()'d by the
>> bundle. The executalbe must be directly in the filesystem since the OS
>> does not know how to read JARs. Native headers don't do it for you since
>> you actually need the real path fo the executable in the file system
>> - a bundle that supplies content to a browser. A help or doc system for
>> exampe. Again, the browser does not know how to look into JARs so the
>> content must be directly in the filesystem and you need a file: url to
>> pass to the browser
>>
>> We've seen both of these (and more) in Eclipse and so added the
>> FileLocator.toFileURL() helper method Erik mentioned. Here is the
>> Javadoc
>>
>> /**
>> * Converts a URL that uses a user-defined protocol into a URL
>> that uses the file
>> * protocol. The contents of the URL may be extracted into a cache
>> on the file-system
>> * in order to get a file URL.
>> * <p>
>> * If the protocol for the given URL is not recognized by this
>> converter, the original
>> * URL is returned as-is.
>> * </p>
>> * @param url the original URL
>> * @return the converted file URL or the original URL passed in if
>> it is
>> * not recognized by this converter
>> * @throws IOException if an error occurs during the conversion
>> */
>>
>> In practice this takes things that you would get back from getResource or
>> getEntry and converts them to file:. In the case of a directory based
>> bundle, the file is likely already directly in the filesystem so its file:
>> url is returned. In the case of a JAR'd bundle, the file (or directory)
>> is extracted to a cache and that location returned.
>>
>> Jeff
>>
>>
>>
>>
>> "Richard S. Hall" <he...@ungoverned.org>
>> 09/13/2006 07:52 PM
>> Please respond to
>> felix-dev@incubator.apache.org
>>
>>
>> To
>> felix-dev@incubator.apache.org
>> cc
>>
>> Subject
>> Re: OSGi URL to file
>>
>>
>>
>>
>>
>>
>> No, there is no standard way, nor any equivalent method in Felix.
>>
>> This is something you could construct for Felix, perhaps, but it seems
>> like bad form since the whole point of getResource() is to eliminate the
>> dependencies on file locations.
>>
>> And what happens if the resource is in a JAR file, then it will never be
>> a file: resource?
>>
>> You might be trying to do something and this is the only way to do it,
>> but it would certainly be better if there was another way.
>>
>> -> richard
>>
>> Erik Bengtson wrote:
>>
>>> Hi,
>>>
>>> I need to convert the URL given by
>>> URL url =
>>>
>>>
>> Bundle.loadClass('something').getClassLoader().getResource('anotherthing');
>>
>>> Using equinox I get "bundleresource://" protocol, so I want to convert
>>>
>> to
>>
>>> file://.
>>>
>>> To convert I use:
>>>
>>> URL fileURL = org.eclipse.core.runtime.FileLocator.toFileURL(url);
>>>
>>> Is there an Felix equivalent or in the OSGI standard?
>>>
>>> Thanks,
>>>
>>> Erik Bengtson
>>>
>>>
>>> PS:
>>> Richard,
>>>
>>> thanks for the previous answer regarding best pratices on dependencies.
>>>
>>>
>>
>
>
>
>
Re: OSGi URL to file
Posted by Erik Bengtson <er...@jpox.org>.
My use case is the following:
I want to modify the bytecode of some classes at runtime.
I thought that I could get a url.getConnection().getOutputStream() to do that,
but it does not seems to work (sort of non supported protocol).
Thanks Jeff and Richard again for the reponses.
Quoting Jeff McAffer <Je...@ca.ibm.com>:
> yes, the usecases for this are somewhat rare but they do come up. Most of
> the time it relates to bundles that supply files to non-OSGi aware
> systems. For example:
> - a bundle that supplies an executable that is in turn exec()'d by the
> bundle. The executalbe must be directly in the filesystem since the OS
> does not know how to read JARs. Native headers don't do it for you since
> you actually need the real path fo the executable in the file system
> - a bundle that supplies content to a browser. A help or doc system for
> exampe. Again, the browser does not know how to look into JARs so the
> content must be directly in the filesystem and you need a file: url to
> pass to the browser
>
> We've seen both of these (and more) in Eclipse and so added the
> FileLocator.toFileURL() helper method Erik mentioned. Here is the
> Javadoc
>
> /**
> * Converts a URL that uses a user-defined protocol into a URL
> that uses the file
> * protocol. The contents of the URL may be extracted into a cache
> on the file-system
> * in order to get a file URL.
> * <p>
> * If the protocol for the given URL is not recognized by this
> converter, the original
> * URL is returned as-is.
> * </p>
> * @param url the original URL
> * @return the converted file URL or the original URL passed in if
> it is
> * not recognized by this converter
> * @throws IOException if an error occurs during the conversion
> */
>
> In practice this takes things that you would get back from getResource or
> getEntry and converts them to file:. In the case of a directory based
> bundle, the file is likely already directly in the filesystem so its file:
> url is returned. In the case of a JAR'd bundle, the file (or directory)
> is extracted to a cache and that location returned.
>
> Jeff
>
>
>
>
> "Richard S. Hall" <he...@ungoverned.org>
> 09/13/2006 07:52 PM
> Please respond to
> felix-dev@incubator.apache.org
>
>
> To
> felix-dev@incubator.apache.org
> cc
>
> Subject
> Re: OSGi URL to file
>
>
>
>
>
>
> No, there is no standard way, nor any equivalent method in Felix.
>
> This is something you could construct for Felix, perhaps, but it seems
> like bad form since the whole point of getResource() is to eliminate the
> dependencies on file locations.
>
> And what happens if the resource is in a JAR file, then it will never be
> a file: resource?
>
> You might be trying to do something and this is the only way to do it,
> but it would certainly be better if there was another way.
>
> -> richard
>
> Erik Bengtson wrote:
> > Hi,
> >
> > I need to convert the URL given by
> > URL url =
> >
> Bundle.loadClass('something').getClassLoader().getResource('anotherthing');
> >
> > Using equinox I get "bundleresource://" protocol, so I want to convert
> to
> > file://.
> >
> > To convert I use:
> >
> > URL fileURL = org.eclipse.core.runtime.FileLocator.toFileURL(url);
> >
> > Is there an Felix equivalent or in the OSGI standard?
> >
> > Thanks,
> >
> > Erik Bengtson
> >
> >
> > PS:
> > Richard,
> >
> > thanks for the previous answer regarding best pratices on dependencies.
> >
>
>
Re: OSGi URL to file
Posted by Jeff McAffer <Je...@ca.ibm.com>.
yes, the usecases for this are somewhat rare but they do come up. Most of
the time it relates to bundles that supply files to non-OSGi aware
systems. For example:
- a bundle that supplies an executable that is in turn exec()'d by the
bundle. The executalbe must be directly in the filesystem since the OS
does not know how to read JARs. Native headers don't do it for you since
you actually need the real path fo the executable in the file system
- a bundle that supplies content to a browser. A help or doc system for
exampe. Again, the browser does not know how to look into JARs so the
content must be directly in the filesystem and you need a file: url to
pass to the browser
We've seen both of these (and more) in Eclipse and so added the
FileLocator.toFileURL() helper method Erik mentioned. Here is the
Javadoc
/**
* Converts a URL that uses a user-defined protocol into a URL
that uses the file
* protocol. The contents of the URL may be extracted into a cache
on the file-system
* in order to get a file URL.
* <p>
* If the protocol for the given URL is not recognized by this
converter, the original
* URL is returned as-is.
* </p>
* @param url the original URL
* @return the converted file URL or the original URL passed in if
it is
* not recognized by this converter
* @throws IOException if an error occurs during the conversion
*/
In practice this takes things that you would get back from getResource or
getEntry and converts them to file:. In the case of a directory based
bundle, the file is likely already directly in the filesystem so its file:
url is returned. In the case of a JAR'd bundle, the file (or directory)
is extracted to a cache and that location returned.
Jeff
"Richard S. Hall" <he...@ungoverned.org>
09/13/2006 07:52 PM
Please respond to
felix-dev@incubator.apache.org
To
felix-dev@incubator.apache.org
cc
Subject
Re: OSGi URL to file
No, there is no standard way, nor any equivalent method in Felix.
This is something you could construct for Felix, perhaps, but it seems
like bad form since the whole point of getResource() is to eliminate the
dependencies on file locations.
And what happens if the resource is in a JAR file, then it will never be
a file: resource?
You might be trying to do something and this is the only way to do it,
but it would certainly be better if there was another way.
-> richard
Erik Bengtson wrote:
> Hi,
>
> I need to convert the URL given by
> URL url =
>
Bundle.loadClass('something').getClassLoader().getResource('anotherthing');
>
> Using equinox I get "bundleresource://" protocol, so I want to convert
to
> file://.
>
> To convert I use:
>
> URL fileURL = org.eclipse.core.runtime.FileLocator.toFileURL(url);
>
> Is there an Felix equivalent or in the OSGI standard?
>
> Thanks,
>
> Erik Bengtson
>
>
> PS:
> Richard,
>
> thanks for the previous answer regarding best pratices on dependencies.
>
Re: OSGi URL to file
Posted by "Richard S. Hall" <he...@ungoverned.org>.
No, there is no standard way, nor any equivalent method in Felix.
This is something you could construct for Felix, perhaps, but it seems
like bad form since the whole point of getResource() is to eliminate the
dependencies on file locations.
And what happens if the resource is in a JAR file, then it will never be
a file: resource?
You might be trying to do something and this is the only way to do it,
but it would certainly be better if there was another way.
-> richard
Erik Bengtson wrote:
> Hi,
>
> I need to convert the URL given by
> URL url =
> Bundle.loadClass('something').getClassLoader().getResource('anotherthing');
>
> Using equinox I get "bundleresource://" protocol, so I want to convert to
> file://.
>
> To convert I use:
>
> URL fileURL = org.eclipse.core.runtime.FileLocator.toFileURL(url);
>
> Is there an Felix equivalent or in the OSGI standard?
>
> Thanks,
>
> Erik Bengtson
>
>
> PS:
> Richard,
>
> thanks for the previous answer regarding best pratices on dependencies.
>
OSGi URL to file
Posted by Erik Bengtson <er...@jpox.org>.
Hi,
I need to convert the URL given by
URL url =
Bundle.loadClass('something').getClassLoader().getResource('anotherthing');
Using equinox I get "bundleresource://" protocol, so I want to convert to
file://.
To convert I use:
URL fileURL = org.eclipse.core.runtime.FileLocator.toFileURL(url);
Is there an Felix equivalent or in the OSGI standard?
Thanks,
Erik Bengtson
PS:
Richard,
thanks for the previous answer regarding best pratices on dependencies.
Re: JMX introspector
Posted by Manuel Santillan <sa...@dit.upm.es>.
Well, thanx for the info!
However, I've already refactored it to use cglib (ASL'd). Anyway, the
more open the better :-)
Cheers!!
Reinhard Poetz escribió:
> Niclas Hedhman wrote:
>> On Sunday 10 September 2006 00:18, santillan wrote:
>>> I've added a new module to the repo: jmxintrospector. It enables the
>>> dynamic generation of proxies to remote objects without having the
>>> interfaces in the classpath. I wanted to check with you if there
>>> were any
>>> licensig issues with it, because it uses the Javassist library.
>>> Javassist
>>> is both Mozilla (MPL) and LGPL licensed (it is part of JBoss, BTW).
>>
>>> It uses it unmodified.
>>
>> More importantly; Can you compile your part without putting this on
>> the compile classpath??
>>
>> If not, it is not an allowed dependency.
>
> according to http://people.apache.org/~cliffs/3party.html MPL 1.0 and
> MPL 1.1 are allowed:
>
> "[...] therefore, software under these licenses may only be included
> in binary form within an Apache product, which must be appropriately
> labeled [...]"
>
Re: JMX introspector
Posted by Reinhard Poetz <re...@apache.org>.
Niclas Hedhman wrote:
> On Sunday 10 September 2006 00:18, santillan wrote:
>> I've added a new module to the repo: jmxintrospector. It enables the
>> dynamic generation of proxies to remote objects without having the
>> interfaces in the classpath. I wanted to check with you if there were any
>> licensig issues with it, because it uses the Javassist library. Javassist
>> is both Mozilla (MPL) and LGPL licensed (it is part of JBoss, BTW).
>
>> It uses it unmodified.
>
> More importantly; Can you compile your part without putting this on the
> compile classpath??
>
> If not, it is not an allowed dependency.
according to http://people.apache.org/~cliffs/3party.html MPL 1.0 and MPL 1.1
are allowed:
"[...] therefore, software under these licenses may only be included in binary
form within an Apache product, which must be appropriately labeled [...]"
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: JMX introspector
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 10 September 2006 00:18, santillan wrote:
> I've added a new module to the repo: jmxintrospector. It enables the
> dynamic generation of proxies to remote objects without having the
> interfaces in the classpath. I wanted to check with you if there were any
> licensig issues with it, because it uses the Javassist library. Javassist
> is both Mozilla (MPL) and LGPL licensed (it is part of JBoss, BTW).
> It uses it unmodified.
More importantly; Can you compile your part without putting this on the
compile classpath??
If not, it is not an allowed dependency.
Cheers
Niclas
Re: JMX introspector
Posted by "Richard S. Hall" <he...@ungoverned.org>.
santillan wrote:
> By the way, would it be possible to define a JMood component at JIRA to
> track its issues, or should I use the "unknown" category?
I will create a component for you in JIRA right now...
-> richard