Hi Martin,
That sounds like a plan. One way you could support backwards
compatibility is to create a temporary file for the resource.
BTW can you hold off doing any commits to the trunk until we release?
and instead please create a branch if necessary.
Paul.
On Feb 11, 2009, at 3:39 AM, Martin Grotzke wrote:
> 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
>