Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #33867 > unrolled thread

Implementing FileSystem without MANIFEST.MF/META-INF/services

Back to article view | Back to comp.lang.java.programmer

Contents

  Implementing FileSystem without MANIFEST.MF/META-INF/services david.raver@gmail.com - 2016-02-23 11:41 -0800
    Re: Implementing FileSystem without MANIFEST.MF/META-INF/services Arne Vajhøj <arne@vajhoej.dk> - 2016-02-23 20:26 -0500
      Re: Implementing FileSystem without MANIFEST.MF/META-INF/services david.raver@gmail.com - 2016-02-24 00:14 -0800
        Re: Implementing FileSystem without MANIFEST.MF/META-INF/services Martin Gregorie <martin@address-in-sig.invalid> - 2016-02-24 18:45 +0000
          Re: Implementing FileSystem without MANIFEST.MF/META-INF/services david.raver@gmail.com - 2016-02-24 12:31 -0800

#33867 — Implementing FileSystem without MANIFEST.MF/META-INF/services

I'm trying to set up a file system (by implementing FileSystemProvider, FileSystem, FileStore, etc.) so that later a user could only call FileSystems.getFileSystem(uri), with a specific URI (custom scheme, host, path, etc).

This is normally done by putting an entry into jar's MANIFEST.MF/META-INF/services, so that a JVM - using that information - can set it up itself, but I don't have that option. I want to do it programmatically. How can this be done?

[toc] | [next] | [standalone]

#33869

On 2/23/2016 2:41 PM, david.raver@gmail.com wrote:
> I'm trying to set up a file system (by implementing
> FileSystemProvider, FileSystem, FileStore, etc.) so that later a user
> could only call FileSystems.getFileSystem(uri), with a specific URI
> (custom scheme, host, path, etc).
>
> This is normally done by putting an entry into jar's
> MANIFEST.MF/META-INF/services, so that a JVM - using that information
> - can set it up itself, but I don't have that option. I want to do it
> programmatically. How can this be done?

Class.forName ????

Arne

[toc] | [prev] | [next] | [standalone]

#33870

On Wednesday, February 24, 2016 at 2:26:32 AM UTC+1, Arne Vajhøj wrote:
> On 2/23/2016 2:41 PM, david...@gmail.com wrote:
> > I'm trying to set up a file system (by implementing
> > FileSystemProvider, FileSystem, FileStore, etc.) so that later a user
> > could only call FileSystems.getFileSystem(uri), with a specific URI
> > (custom scheme, host, path, etc).
> >
> > This is normally done by putting an entry into jar's
> > MANIFEST.MF/META-INF/services, so that a JVM - using that information
> > - can set it up itself, but I don't have that option. I want to do it
> > programmatically. How can this be done?
> 
> Class.forName ????
> 
> Arne

Yes, that works (it would be even simpler to just call a constructor of my extension of FileSystem class). But...

But it requires knowledge of class name and, more importantly, even an instance of class loader that has to be used to load/define a class (using Class.forName(String, boolean, ClassLoader)). I can't expose that to the user.

The platform would have to initialize everything before handing control to the user. The user would then get the FileSystem instance using an URI, like I described above.

[toc] | [prev] | [next] | [standalone]

#33872

On Wed, 24 Feb 2016 00:14:13 -0800, david.raver wrote:

> On Wednesday, February 24, 2016 at 2:26:32 AM UTC+1, Arne Vajhøj wrote:
>> On 2/23/2016 2:41 PM, david...@gmail.com wrote:
>> > I'm trying to set up a file system (by implementing
>> > FileSystemProvider, FileSystem, FileStore, etc.) so that later a user
>> > could only call FileSystems.getFileSystem(uri), with a specific URI
>> > (custom scheme, host, path, etc).
>> >
>> > This is normally done by putting an entry into jar's
>> > MANIFEST.MF/META-INF/services, so that a JVM - using that information
>> > - can set it up itself, but I don't have that option. I want to do it
>> > programmatically. How can this be done?
>> 
>> Class.forName ????
>> 
>> Arne
> 
> Yes, that works (it would be even simpler to just call a constructor of
> my extension of FileSystem class). But...
> 
> But it requires knowledge of class name and, more importantly, even an
> instance of class loader that has to be used to load/define a class
> (using Class.forName(String, boolean, ClassLoader)). I can't expose that
> to the user.
>
But you can provide the equivalent of a login command that prompts the 
user for the URI as well as authentication details, e.g. user name, 
password. 

> The platform would initialize everything except the FileSystem before 
>handing control to the user.

The user issues the login command, which accepts the URI and 
authentication details from the user.

Once the user has been authenticated login command would then get the 
FileSystem instance using a class name that's related to the the user-
supplied URI[1], carry out FileSystem-specific initialisation and then 
hand control back to the user.

You'd also need a logout equivalent to cleanly shut down and disconnect 
the FileSystem when the user wants to quit and/or change FilingSystems.

[1] Its your job to specify the relationship between URI and class name 
and implement a mechanism for storing them and retrieving the class name 
for any valid URI and calling Class.forName() to obtain a FileSystem 
instance. Since you've said there's a relationship between URI and class 
name but given no additional details we can't say anything more about 
that.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#33873

On Wednesday, February 24, 2016 at 7:48:29 PM UTC+1, Martin Gregorie wrote:
> But you can provide the equivalent of a login command that prompts the 
> user for the URI as well as authentication details, e.g. user name, 
> password. 

This has nothing with any sort of logging in.

> > The platform would initialize everything except the FileSystem before 
> >handing control to the user.
> 
> The user issues the login command, which accepts the URI and 
> authentication details from the user.

And it has nothing with the way URI data is passed to add fro.

> Once the user has been authenticated login command would then get the 
> FileSystem instance using a class name that's related to the the user-
> supplied URI[1], carry out FileSystem-specific initialisation and then 
> hand control back to the user.
> 
> You'd also need a logout equivalent to cleanly shut down and disconnect 
> the FileSystem when the user wants to quit and/or change FilingSystems.
> 
> [1] Its your job to specify the relationship between URI and class name 
> and implement a mechanism for storing them and retrieving the class name 
> for any valid URI and calling Class.forName() to obtain a FileSystem 
> instance. Since you've said there's a relationship between URI and class 
> name but given no additional details we can't say anything more about 
> that.

That's right. It's my job to specify the relationship, not the user's/client's. So this rules out the Class.forName() on the user's/client's side, right? The client should be oblivious of the implementing class itself. The only thing the user/client is required to know is the structure of the URI. 

After that, the FileSystem (regardless of the actual implementing class) can be obtained by calling FileSystems.getFileSystem(URI).

All I want is to know if that's possible. And if it is, how it can be done.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web