On Fri, Oct 2, 2009 at 11:26 AM, Toni Menzel <[email protected]> wrote: > I think this is not feasible. > If you want to overwrite resource localization, thats what URLs and URL > Handlers are made for. > There you can make all kinds of things (not sure if you can overwrite built > in protocols like file).
You can. regards, Karl > Or you come up with an abstracted resource api (i think there are tons out > there). > > Toni > > On Fri, Oct 2, 2009 at 11:14 AM, Baptiste Gaillard > <[email protected]>wrote: > >> >> The main problem is that we do not have control on the OSGI components >> deployed on our application because they are developped by our customers. >> >> We can write a guide and explain what to do and not to do with OSGI, but we >> hoped to solve the majority of problems otherwise. >> >> What I wanted to do with: >> new File("relative_path") >> >> is to change the way relative paths are built by replacing java.io.File() >> with our version of java.io.File(). >> >> Something like : >> >> /** >> * Our version of java.io.File >> */ >> class File { >> >> public File(String relativePath) >> { >> this.path = >> fs.normalize(StaticBundleAccessor.getBundle().getBundleLocation().getAbsolutePath() >> + '/' + relativePath); >> this.prefixLength = fs.prefixLength(this.path); >> } >> >> } >> >> /** >> * SUN version of java.io.File >> */ >> class File { >> >> >> >> public File(String pathname) >> >> { >> >> this.path = fs.normalize(pathname); >> >> this.prefixLength = fs.prefixLength(this.path); >> >> } >> >> >> >> } >> >> Do you think something like that is feasible ? >> >> >> >> >> > Date: Fri, 2 Oct 2009 10:51:21 +0200 >> > Subject: Re: OSGI bootdelegation and java.io.File ? >> > From: [email protected] >> > To: [email protected] >> > >> > On Fri, Oct 2, 2009 at 10:48 AM, Baptiste Gaillard >> > <[email protected]> wrote: >> > > >> > > Hi, we are building a platform which allow to deploy and execute OSGI >> components. >> > > >> > > Those OSGI components are developed by our customers and we do not have >> control one those components. >> > > The application is a JEE one and is deployed inside JBoss AS, we also >> use an embedded Felix container. >> > > >> > > We have encounter problems when OSGI components do things like that in >> their code: >> > > >> > > File file = new File("relative_path/myfile.txt"); >> > > >> > > This return a file which point to >> %JBOSS_HOME%/relative_path/myfile.txt. >> > > This seems perfectly normal because OSGI delegate Class Loading for >> 'java.*' classes used to the parent Class Loader. >> > > >> > > So, how is it possible to have a path to the Bundle location (we use >> unzipped bundles) instead of %JBOSS_HOME% by calling new >> File("relative_path") ? >> > > Is it possible to force OSGI to load delegate the Class Loading for >> java.io.File classes ? >> > >> > No. That is not possible. However, I'm not sure I really understand >> > what it is you are trying to do. Can you tell us more about that - >> > maybe there is a different solution to your problem... >> > >> > regards, >> > >> > Karl >> > >> > > Thanks, >> > > >> > > >> > > Baptiste >> > > >> > > >> > > >> > > >> > > _________________________________________________________________ >> > > Découvrez toutes les possibilités de communication avec vos proches >> > > http://www.microsoft.com/windows/windowslive/default.aspx >> > >> > >> > >> > -- >> > Karl Pauls >> > [email protected] >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> _________________________________________________________________ >> Découvrez toutes les possibilités de communication avec vos proches >> http://www.microsoft.com/windows/windowslive/default.aspx >> > > > > -- > Toni Menzel > Independent Software Developer > Professional Profile: http://okidokiteam.com > [email protected] > http://www.ops4j.org - New Energy for OSS Communities - Open > Participation Software. > -- Karl Pauls [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
