users@jersey.java.net

Re: [Jersey] WADL generator resource loading uses the wrong class loader

From: Jakub Podlesak <Jakub.Podlesak_at_Sun.COM>
Date: Fri, 13 Feb 2009 17:18:50 +0100

On Fri, Feb 13, 2009 at 01:27:08PM +0100, Jakub Podlesak wrote:
> On Fri, Feb 13, 2009 at 12:10:58PM +0100, Paul Sandoz wrote:
> > Are you sure you are using the latest code from 1.0.3-SNAPSHOT? did you
> > update your local SVN?
>
> I have taken the jersey bits from our internal UC repo.
> (After uploading a fresh module up there)
>
> But you are probably right, will build jersey locally and use
> the output for verification to eliminate something going wrong
> in the middle of the way.

When building both, jersey.jar for gfv3 instance and the example
war from the trunk (with tweaked pom, changing scope of some deps to provided),
wadl generation seems to work fine (but not the items resource).

Also generate-wadl example (from trunk) fails to build for my machine
and jdk 1.5 (needed to exclude it from build cycle in order to build whole jersey).
Since hudson job has been successful for recent builds,
i suspect something is wrong with my box configuration.

Need to leave now, but will try to explore further later
and provide more precise info.

~Jakub

>
> ~Jakub
>
> >
> > Caused by: java.lang.RuntimeException: The file '/application-doc.xml' does
> > not exist in the classpath. It's loaded by the generator class, so if you
> > use a relative filename it's relative to the generator class, otherwise you
> > might want to load it via an absolute classpath reference like
> > classpath:/somefile.xml
> > at
> > com.sun.jersey.api.wadl.config.WadlGeneratorLoader.setProperty(WadlGeneratorLoader.java:137)
> > at
> > com.sun.jersey.api.wadl.config.WadlGeneratorLoader.loadWadlGenerator(WadlGeneratorLoader.java:113)
> > at
> > com.sun.jersey.api.wadl.config.WadlGeneratorLoader.loadWadlGeneratorDescriptions(WadlGeneratorLoader.java:96)
> > at
> > com.sun.jersey.api.wadl.config.WadlGeneratorConfig.getWadlGenerator(WadlGeneratorConfig.java:147)
> > ... 42 more
> >
> >
> > The line numbers in the above do not correspond correctly with the latest
> > code. For example WadlGeneratorLoader.setProperty is now between lines 151
> > and 232
> >
> > Paul.
> >
> > On Feb 13, 2009, at 12:01 PM, Jakub Podlesak wrote:
> >
> >> On Fri, Feb 13, 2009 at 11:13:33AM +0100, Paul Sandoz wrote:
> >>>
> >>> On Feb 13, 2009, at 1:23 AM, Martin Grotzke wrote:
> >>>
> >>>> Hi Paul,
> >>>>
> >>>> holding the commit was fairly easy. :)
> >>>> And also congrats to the release!
> >>>>
> >>>
> >>> Thanks!
> >>>
> >>>
> >>>> 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.
> >>>>
> >>>
> >>> Thanks.
> >>>
> >>>
> >>>> 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.
> >>>>
> >>>
> >>> I just changed it to fixed, it works in the trunk.
> >>>
> >>> Jakub or I need to verify against an installation in GF. Once done we
> >>> will
> >>> mark it as verified.
> >>
> >> Tried to verify, but got:
> >>
> >> remote failure: Exception while deploying the app : java.lang.Exception:
> >> java.lang.IllegalStateException: ContainerBase.addChild: start:
> >> LifecycleException: java.lang.RuntimeException: Could not load
> >> WadlGeneratorConfiguration, check the configuration of
> >> com.sun.jersey.config.property.WadlGeneratorConfig
> >>
> >> when deploying the app. Attaching also my [server.log] file with stack
> >> trace.
> >>
> >> Any thoughts?
> >>
> >> ~Jakub
> >>
> >>>
> >>> Paul.
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> >>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >>>
> >> <server.log>---------------------------------------------------------------------
> >> 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>