Hi,
I just started to change the file stuff to input stream, also in the
existing WadlGenerator implementations (resourcedoc, grammars,
application doc).
I just realized that this (only do InputStream, not File) would require
also a change of the maven-wadl-plugin (GenerateWadlMojo), as this right
now also uses files (using the absolute path, not the classpath).
I see two options:
1) Only support InputStream (not File) in existing WadlGenerator
implementations (WadlGeneratorApplicationDoc,
WadlGeneratorGrammarsSupport, WadlGeneratorResourceDocSupport)
1.1) users of extended wadl at runtime (using WadlGeneratorConfig)
would need to change this configuration (unless we implement
some backwards compatibility stuff, what would be not "nice"
IMHO: 1) the property names would not reflect what they are; 2)
the old "classpath:" prefix would have to be supported, absolute
file references could not be supported depending on the
classloader)
1.2) users of extended wadl at build time (maven-wadl-plugin) would
need to change their configuration, so that files are available
in the classpath
2) Keep the file support in the WadlGenerator implementations
(WadlGeneratorApplicationDoc, WadlGeneratorGrammarsSupport,
WadlGeneratorResourceDocSupport) and add InputStream capability
2.1.) the same as 1.1)
2.2.) no change required for wadl at build time
I would suggest door 2)
In either case I would suggest to drop the "classpath:" stuff from the
WadlGeneratorConfig (as it does not make any sense any more and we
cannot have support for absolute paths either) and to have proper names
for the InputStream properties (e.g. resourceDocInputStream in addition
to resourceDocFile). I don't see any way how to make the complete change
fully backwards compatible (unfortunately).
What do you think?
Any objections from existing users of extended wadl stuff?
Cheers,
Martin
On Tue, 2009-02-10 at 16:53 +0100, Paul Sandoz wrote:
> Hi Martin,
>
> FYI see here:
>
> https://jersey.dev.java.net/issues/show_bug.cgi?id=207
>
> Before we release 1.0.2 we have been testing Jersey installed onto GF
> so that the Jersey jars do not need to be included in the war file.
>
> The problem is i think the current resource loading technique of
> com.sun.jersey.api.wadl.config.WadlGeneratorLoader is incorrect. It
> assumes that:
>
> 1) It can use the class loader of the wadl generator, which by
> default belongs to Jersey and if part of GF will be loaded by
> a different class loader; and
>
> 2) assumes that resource can be resolved to a File. Instead it
> should be InputStream.
>
> I think what we need to do what the MultiPart does for loading a
> resource, which does:
>
> ClassLoader loader =
> Thread.currentThread().getContextClassLoader();
> if (loader == null) {
> loader = this.getClass().getClassLoader();
> }
>
> // Attempt to find our properties resource
> InputStream stream = null;
> try {
> stream =
> loader.getResourceAsStream(MULTI_PART_CONFIG_RESOURCE);
> if (stream == null) {
> return;
> }
>
> Paul.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net