Stuart McCulloch wrote:
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)
I think exception is a better choice (as is the current case) when
reference semantics can't be supported. So, I am OK if there is no
change made. See below for a description of my use case.
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?
What I wanted to do was directory deployment with MANIFEST.MF
replacement. So, it involved both reference: scheme (for directory
deployment) and my custom webbundle: scheme (for MANIFEST .MF
processing). The reason for directory deployment was to allow users to
change JSP pages in the source directory and see the effect immediately
next time when they accessed the JSP over the web. Without directory
deployment, they would have had to package the changed JSPs and update
the bundle. Since, this is all happening in the development
environment, I feel performance is not a big concern here. Plus, network
is actually not involved here.
I am fine if this is not considered a valid use case.
Thanks,
Sahoo
