2009/6/8 Sahoo <[email protected]> > Stuart McCulloch wrote: > >> 2009/6/8 Sahoo <[email protected]> >> >> Stuart McCulloch wrote: >>> >>> >>>> I guess I'm not seeing why you want to use the reference: scheme with >>>> non-file URLs? >>>> >>>> do you just want to avoid copying the remote content locally or is there >>>> another reason? >>>> >>>> Good question. I want to modify the content as it is read. e.g., I want >>> to >>> process the MANIFEST.MF by having my own URL handler for a custom >>> protocol. >>> All these work as long as I don't use reference scheme. >>> >> >> Ah, ok - I think I understand now. >> >> You want to have "reference:" in the URL and have Felix ignore it for >> non-"file:" schemes. >> >> > Not really. >
hmm, well at the moment it throws an exception which I doubt you want ;) but seriously the only alternative is to log a message and treat it as a non-reference URL (see below) > > ie. log a warning / info / debug and continue as if the URL was not a >> "reference:" instead >> of throwing an exception as it currently does. >> >> > I just want Felix to read the content off the JarInputStream when it > encounters a non-file URL after reference:. Is there a reason why Felix must > copy? Is performance the reason? yes - as Richard pointed out we need access to the file, remotely querying a jar over the network is very slow compared to copying it and querying locally What if the custom url handler is already backed by a JarFile object? > problem is we have no way of knowing that - we'd have to repeatedly query through the handler, which could also be slow > Let's put it this way. How can we have directory deployment of bundles with > support for content filtering? > isn't this what the various OPS4J URL handlers do? they let you install and auto-wrap jars into bundles, etc. as you say everything works when you don't have "reference:" in front of your custom URLs, so what's the benefit that you expect to gain from adding it? > Thanks, > Sahoo > -- Cheers, Stuart
