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 <[EMAIL PROTECTED]>: > 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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> > > > 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" <[EMAIL PROTECTED]> > > >> 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. > > >>> > > >>> > > >>> > > >> > > >> > > > > > > > > > >
