[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[jetty-users] Is there a reason for not including a setContainer on Server?
|
I'm setting up Jetty in a Spring context. First note - the docs are out of date with old package references and use of deprecated classes (WebAppDeployer). Maybe I'll be in a position to update them when I get through it all.
For now I'm wrappering Jetty in my own bean because there are at least 2 non-bean friendly classes. One is fixed (that was the quickest bug fix I ever saw, amazing, just hours after I posted it). The other I've noted (so far...) is that the deployment manager needs to be added to the Server Container via a call to Server.addBean(...).
Now there's a Server.getContainer(...) method, but no setter for the same. If there were a setter I could construct the containter as a bean and inject it to Server (this would also require that Container be re-wired as a bean or at least offer a constructor option to initialize with a list of Objects).
Perhaps following bean standards isn't a priority, not sure, but just thought I'd pose the thoughts (maybe I'm off base somewhere that someone will note). As is I can't find a good way to cleanly launch Jetty 7.x under Spring without a wrapper (unless I use JavaConfig possibly, but then a wrapper just seems to be easier).
Thanks,
Dave