Hum, yes using BundleContext.getDataFile() would be a good idea, but in our 
case we can't do that.

I explain me a little more...

In fact our customers are developping components using a framework called UIMA 
(http://incubator.apache.org/uima/). 
To deploy the components on our platform, control the Class 
Loading/UnLoading/etc. we have added an OSGI layer. 
Now, the components are OSGI wrappers around UIMA components.
Unfortunately in UIMA components we do not have access to 
BundleContext.getDataFile() :-(

> Replace File via the boot class path, as Karl mentions, is do-able, but 
> I am not sure if it is a good idea.

I agree, this should work well to solve the 'new File(relativePath)' problem. 
But as the application is deployed in JBoss AS there will be lot of other 
problems... Jboss will not be able to find his files... 
Perhaps it's feasible via the boot class path but the 'java.io.File' class to 
developp will be very compilcated.

Thanks, 

Baptiste
 
> Date: Fri, 2 Oct 2009 11:34:13 +0200
> From: [email protected]
> To: [email protected]
> Subject: Re: OSGI bootdelegation and java.io.File ?
> 
> You certainly need to tell your customers to use 
> BundleContext.getDataFile() instead of creating file objects directly.
> 
> Replace File via the boot class path, as Karl mentions, is do-able, but 
> I am not sure if it is a good idea.
> 
> -> richard
> 
> On 10/2/09 11:23, Karl Pauls wrote:
> > Well, in this case I guess you will have to have your customers
> > special case for OSGi I guess as their is no way (that I know) to
> > replace java.io.File (unless you override it with our own version
> > using the -Xbootclasspath/p option of the jvm).
> >
> > regards,
> >
> > Karl
> >
> > 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
> >>      
> >
> >
> >    
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 
                                          
_________________________________________________________________
Inédit ! Des Emoticônes Déjantées! Installez les dans votre Messenger !
http://www.ilovemessenger.fr/Emoticones/EmoticonesDejantees.aspx

Reply via email to