users@jersey.java.net

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

From: Jakub Podlesak <Jakub.Podlesak_at_Sun.COM>
Date: Thu, 19 Feb 2009 18:54:09 +0100

On Fri, Feb 13, 2009 at 05:18:50PM +0100, Jakub Podlesak wrote:
> 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).

This is to confirm extended-wadl-example works fine now.
I have configured a separate context-root for it and will re-add
the example to the glassfish modules.

>
> 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.

Still having issues with jdk5 and generate-wadl example.
Attaching mvn -e clean install output.

Any suggestions?

~Jakub

>
> 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>