Hi Paul,
holding the commit was fairly easy. :)
And also congrats to the release!
I modified the plan: I kept support for Files in the WadlGeneratorLoader
(and related files), as in some environments Files can be used and then
nobody has to change anything if it was working already. So we have it
fully backwards compatible.
I just added the support for InputStream properties (in
WadlGeneratorLoader) and added props taking an InputStream to the
existing WadlGenerators.
The extended-wadl-webapp sample is also updated:
SampleWadlGeneratorConfig now configures the InputStream properties of
the WadlGenerators.
Can I somehow reproduce the issue you ran into with GF? Or do you just
want to verify that the encountered problem is solved with this
solution? I didn't change issue 207 ([1]) to fixed as I wasn't sure
about this.
Cheers,
Martin
[1]
https://jersey.dev.java.net/issues/show_bug.cgi?id=207
On Wed, 2009-02-11 at 09:50 +0100, Paul Sandoz wrote:
> 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
--
Martin Grotzke
http://www.javakaffee.de/blog/